你需要从一开始就着手于软件设计，应该从立项之初就致力于将架构设计的简约明了。

对于我全权负责的项目，我们的开发策略是，除非架构设计支持轻松地将该功能实现，否则我们绝不允许新增该功能。

这会让有些人抓狂，特别是对于那些无法对未来做出判断的人而言更是如此。他们会开始口若悬河地唠叨：“我们等不及了！这个功能非常重要！”又或者是：“现在只管把它加进来就好了，完事之后我们会把代码整理重构的！”他们从没有意识到他们的态度一向如此。等到下一次需要添加另一个功能有求于我们时，他们还会说出同样的话。

如果你不考虑未来，那么你所有的代码都会陷入糟糕的设计和极度的复杂之中。

最终代码看上去就如弗兰肯斯坦的怪物一般。

如果只是新增很少的功能，并在稍后将它重构的话就不太可能出现这种问题。但如果空降一个架构无法支撑的大型功能，还计划在完成之后尝试整理代码，那这将会是一项艰难的任务。所以说功能的体量很重要。

以正确的方式开始

最糟糕的情况是，在你允许人们在几个月或几年内不经过提前设计就往代码中新增功能，然后有一天你幡然醒悟并意识到系统有可能撑不住了。此时你唯一的选择只能是修复整个代码库。这注定会是一项艰巨的任务，因为就像新增功能一样，它无法一气呵成，除非你想要重写整个应用。

如果你想要开始以正确的方式行事，那么你必须以正确的方式立即行动起来。为了解决当下的问题，你必须将整个流程拆分为简单的步骤，并逐步对设计中存在的缺陷予以修复。这通常需要数月甚至数年的工作投入——简直就是浪费。因为你本应该从一开始就将架构设计好，这样的话，这些问题从根本上就可以避免。你应该事先把目光放长远一些。

如果你的项目缺乏严格的架构设计，并且它的体量还一直在持续增长，那么终有一天超乎你想象的复杂性会让你束手无策。

这并不意味着你从一开始就需要设计能足够满足未来所有需求的大型通用架构，并且现在就实现它。上述观点想表达的是，你需要在工作中学习应用本书和《简约之美》中讨论的那些软件设计原则，这样从一开始你就会拥有一个可理解的、简约的并具有可维护性的系统。