软件架构的终极目标是用最小人力成本满足系统全生命周期需求

判断一个软件架构好坏的标准很简单：用最小的人力成本来满足构建和维护该系统的需求。如果这个成本在系统整个生命周期内一直维持较低水平，架构就是优良的；如果每次发布都会抬高下一次变更的成本，架构就是不好的。一个真实公司的案例把这个标准的分量具体化：工程师团队规模持续增长（看起来是业务成功的标志），但同期用代码行数衡量的生产效率却在下滑，每行代码的平均变更成本随版本迭代一路飙升，到第8个版本时构建成本已经是第1版的40倍——部门月工资从10万美元涨到2000万美元，而最初的十几万美元带来的新功能收益，远比后来的2000万美元产出的价值高得多。这条曲线揭示的规律是：架构质量的好坏不体现在系统刚上线那一刻，而体现在成本曲线随时间的斜率上——一个”能跑起来”的系统和一个”架构良好”的系统区别，只会随着版本迭代逐渐显现，等发现问题时往往已经积累了相当规模的技术债。发散：这条判断标准把”架构好坏”从主观审美问题变成了可以用曲线量化观测的工程问题，为后续SOLID原则、组件耦合这些具体技术手段提供了统一的评判尺度——任何设计决策最终都要回答”它是拉低还是拉高了未来变更的边际成本”。