重新润色后的内容：

从任何一个视角去审视软件系统，都无法做到完美无瑕。若从架构学角度去分析，虽能在一定程度上做到抓住主要矛盾，但无可避免地会遗漏一些细微信息。软件架构学的核心焦点在于组织结构（structure）。无论是组件、类、函数、模块，还是层级、服务，乃至微观与宏观的软件开发过程，软件的组织结构都是我们关注的重点。然而，现实中的软件项目并不总是如我们所愿，它们犹如庞大的国企，层层嵌套，错综复杂。

与物理建筑不同，无论其地基是石是土，无论其形态是高是矮，无论其风格是宏伟还是精致，其组织结构一目了然，且必须遵循“受重力”这一自然规律。而软件项目则没有固定的规律可循。此外，物理建筑是由标准的建筑材料如砖、水泥、木材、钢铁或玻璃等构成，而大型软件项目则是由小软件组件构成，这些组件再由更小的组件构成，如此层层叠加，无穷无尽。

因此，当谈及软件架构时，必须意识到软件项目的递归和分形特性，最终都会由一行行代码组成。离开代码和具体细节设计，架构设计便无从谈起。虽然物理建筑可以通过比例模型来分层描述细节，但软件项目的内部结构却很难用模型来描绘。软件项目同样具有内部结构，但其结构无论在数量还是多样性上，都远超物理建筑。

可以说，软件开发需要比建造物理建筑更长、更专注的设计过程，软件架构师应该比建筑架构师更懂架构！

尽管比例模型是常见的展示方式，但无论PowerPoint图表中的彩色方块多么精美、多么易懂，它都无法完全代表一个软件的架构。它只是一个视图，而非全部。软件的架构没有固定展现形式，每个视图背后都是架构师所做出的层层选择。一个视图包含了哪些部分，排除了哪些部分；用特殊形状和颜色强调了哪些部分，又有哪些部分被一笔带过，甚至直接忽略，这些都是该视图的特性。然而，每个视图都是正确的，它们之间并没有优劣之分。

尽管软件难以用比例模型展示，但它终究要在现实世界中运行。在设计软件架构时，我们必须理解和遵守现实的约束条件。CPU速度和网络带宽往往决定系统的性能，而内存和存储空间的大小也会极大地影响代码的设计。

正如威廉·莎士比亚所说：“人的欲望是无止境的，而行动却不得不遵从现实的限制。”人类的经济活动都存在于现实世界中，因此我们可以利用现实世界的一些准则来衡量和推理软件开发过程中那些难以量化和物化的因素。

软件架构是系统设计过程中的重要决定集合，每个决定的重要性可以通过变更成本来衡量。Grady Booch指出，需要付出的时间、金钱和人力成本是区分软件架构规模大小的衡量标准，也是区分架构设计和细节设计的依据。一个好的架构，不仅要在某一特定时刻满足软件用户、开发者和所有者的需求，更要在一段时间内持续满足他们的后续需求。

如果你觉得好的架构成本太高，那么可以选择差的架构再加上返工的成本。Brian Foote 和 Joseph Yoder强调，一个系统的常规变更不应该成本高昂，也不应该需要大型设计调整，更不应该需要单独立项来推进。这些常规变更应该融入日常系统维护中完成。

那么，我们如何预知系统未来的变更需求，以便提前做准备呢？在没有水晶球和时光穿梭机的情况下，如何预测未来，降低未来的变更成本呢？

Ralph Johnson认为，软件架构是你希望在项目一开始就能做对，但不一定能够做得对的决策的集合。了解历史已经够难了，我们对现实的认知也不可靠，预测未来更是难上加难。

这就是不同的软件开发理论的主要分歧点。其中一条路线认为，只有权威和刚性才能带来强壮与稳定。如果某项变更成本高昂，那么就应该忽视它——变更背后的需求要么被抑制，要么被官僚主义的大机器绞碎。架构师的决定永远是完整的、彻底的，软件架构是全体开发人员的噩梦，是沮丧的源泉。

而另一条路线则充斥着大量的投机性通用设计。在这样的软件项目中，到处都是硬编码的猜测性代码，到处都是无穷无尽的参数，存在成篇累牍的无效代码。维护这样的项目，肯定会遇到意外情况，而且无论预留多少资源都不够应付。

通过实际创造和探索，不断提出问题并进行实验。优良的软件架构不是一成不变的，它需要在实践中不断打磨和改进。软件架构是一个猜想，只有通过实际实现和测量才能证实。遵循这条路线，我们需要用心，全神贯注，不停观察和思考，在原则指导下不断实践。虽然这听起来可能很麻烦、很慢，但只要坚持下去，就一定能够成功。

正如Robert C.Martin所说：“走快的唯一方法是先走好。”