如果没有所谓的“Deadline”（最后期限），我们就不用担心架构设计的问题，因为我们有足够的时间去研究去学习找到最优的架构设计方案。然而，做梦是可以有的。那怎么寻找？相信大家都各有各的看法，基本分为这几派：
-
梭哈派，不要给我说什么架构设计、设计思维！老夫架构设计就是敲代码，边敲边设计，自然而然代码就是架构，想那么多还不如直接敲。
梭哈派 - 借鉴派，善于借鉴业界成熟项目的标准，都按成熟标准来就好。
- 灵活派，根据实际项目需求来做架构设计，最好看现场情况来判断。
- 文档派，都得写文档，写完整了文档，就能预防后续的问题和风险。
肯定不止上面的介绍的对于架构设计的看法，相信大家都有自己认同的看法，欢迎评论区留下“最强流派”。
那架构设计的最佳平衡点肯定会有架构大师做了研究的，下面将从专业的研究分析下。
架构设计对总工期的影响
参考Barry Boehm《Architecting: How Much and When?》书中项目工期的构成：开发、架构设计、返工（处理技术债：打补丁、改BUG、重构、重写）（见图2）。
图2 项目工期的构成
可见，Boehm证明了随着架构设计时间的增加，开发和返工量都会减少。书中还详细地研究了系统规模影响最佳构架设计的平衡点，鉴于国内外的项目情况不同，本文就不作为参考了。但从中还是可以得出以下个人认为比较客观的结论：
- 系统越大，前期做架构设计的获益越大，反之越小。
- 一千万行代码以上的大项目在总工期上架构设计时间占3到4成较好，不超过一万行代码的小项目则不超过1成。
- 前期架构设计做得不够，后期做好返工的心理准备。
架构设计的时间决定
上节内容用系统规模来评估架构设计的工作量似乎很符合“灵活派”的做法，因为可以根据项目需求很容易确定系统的规模。相信肯定有人会问：那复杂度不要考虑吗？大型系统可能很复杂，但有“借鉴派”的成熟解决方案就不必做太多架构设计。然而，也并非所有复杂度高的系统都很庞大。
因此，评估前期架构设计的时间，不能只按标准、经验、代码量、复杂度来决定。应该是按照风险来驱动架构设计（下篇文章再详细讲解），当然这也是Boehm做的研究（见《Using Risk to Balance Agile and Plan-Driven Methods》）。
总结
无论是如何寻找架构设计的最佳平衡点，都要遵循《架构设计思维原则》和运用《架构设计思维模式》来做架构设计，因为这些设计思维原则和模式非常有助于实现风险驱动架构设计，找到架构设计的最佳平衡点。
