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