优秀软件不是构建出来的，而是培育起来的

作者：比尔·德·霍拉

作为架构师，负有初始化软件系统的结构并对之进行规划的责任。软件系统会随着时间生长变化，要返工修改，要能和其他系统通信交互——而这一切几乎都会以你和利益相关者无法预见的方式发生。虽然我们顶着架构师的头衔，也从建筑和工程领域里借用了许多隐喻（metaphor），但是优秀软件不构建出来的，而是培育起来的。

单凭规模大小，便可窥见软件成败的端倪；细思之下便可知，在一开始就要设计庞大的系统几乎毫无好处可言。然而，有时我们都会无法抵制如此行事的引诱。除了易于招致额外的复杂性和惯性，前期便要设计庞大的系统，意味着项目会变得更为大型，而大型项目更可能会失败，更可能无法验证，更可能脆弱不堪（fragile），更易产生不必要和无用的产物，成本可能更是无比高昂，而且，更易招致不利的政治因素。

因此，无论多么诱人，都要抵制住试图设计出庞大完整的系统，来“满足甚至或超出”己知需求和特性期望的想法。要有宏伟的远景（grand vision），但不要有庞大的设计。环境和需求的变化不可避免，你和你的系统都要学会适应变化。

如何做到这一点？确保软件系统能够演化和具备适应性的最好办法，是从一开始就做到这样。引导系统进行演化，意味着要从一个小型便可用的系统（a small running system）开始，这个系统是预期架构一个可用的子集，亦即最简单的可行实现。这一新生系统拥有很多期望的特性，在架构上可以教给我们很多西，这些是庞大系统和一大堆架构文档永远无法给予我们的。很可能你自身也己参与到系统的实现中了。由于没有庞大的体表面积，这样的系统更易测试，耦合性也会很低。因此，开发团队也会相对较小，项目协调所需的开销由此也可降抵。其特性也更为清晰易见。系统便易于部署。你和团队也会在第一时间知道什么可行或什么不行。它会揭示出，系统在哪里己经僵硬固化、变得脆弱甚至可能断裂，因而无法轻松进行演化。也许，最为重要的是，由于利益相关者从一开始便可参与到整体设计中，系统对他们会显得实在确凿，易于理解。

设计尽可能小的系统，帮助成功交付，并推动它向宏伟的远景目标不断演化。虽然听想来似乎是放弃了控制权，甚至是在逃避责任，但是最终，利益相关者会感谢你。注意，不要把这种演化式方法和消减需求、规范混乱和生产废品这样的做法混淆在一起。