设计恰如其分的架构.docxVIP

设计恰如其分的架构 张逸 2021-12-18 远在2009年，Martin Fowler与Rebecca Parsons在QCon SF做了一次题为Agilists and Architects: Allies not Adversaries Presentation的演讲。演讲次要争辩了在灵敏方法中的架构活动。 相像的话题，Neal Ford则提出了紧急设计的概念，并发表了名为Evelutionary Architecture and Emergent Design(演进架构与紧急设计)的系列文章。这是很棒的一个讲解演进架构的系列文章，谈到了TDD、代码复用、连贯接口、DSL、重构、惯用法模式、目标等与演进架构和紧急设计有关的内容。 Neal Ford对软件架构的次要观点基于如下现实： · 将来是不行猜测的； ·?软件设计的最终目标是获得完整的源代码； ·?系统的简单度分为偶发简单度（accidental complexity）与本质简单度(essential complexity); 于是，我们应当选择在最终责任时辰（Last Responsible Moment)去应对系统的简单度。所谓“最终责任时辰”，即我们假如未准时实行措施，可能导致简单度线性添加的时辰，如下图所示： 最终责任时辰 Ford提出的方法就是在开发中擅长发觉笼统与模式，并借助测试驱动开发，利用重构去导向设计。同时，我们还可以尝试使用一些考量代码质量的工具，获得质量目标，通过这些目标去发觉问题（这些问题其实就是技术债），然后去准时处理问题。针对较难做出的架构决策，则可以利用Spike方式快速得出结论，甚至是原型方案。 现实上，演进式架构这个话题已经是老调重弹。让我们再回到2004年，Martin Fowler当然发表了文章Is Design Dead。文中谈到了方案式设计与演进式设计之间的区分。这篇文章算得上是溯本清源。 在2007年我本人的书《软件设计精要与模式》中，也简约阐述了我对二者的理解。我给出了一个建筑学的隐喻：拙政园与周庄。 拙政园是方案式设计的典范，没有详尽的方案，或许就不会有疏朗高雅的拙政园。周庄却并非某人在某一时辰灵感捕获后的设计成果，而是经受了数百年的历史沧桑，渐进地添加与更替各种建筑，最终构成现在这般灵秀的水乡风貌。我在书中写道： 演进的设计，同样需要遵照架构设计的基本准绳，它与方案的设计独一的区分是设计的目标。演进的设计提倡满足客户现有的需求；而方案的设计则需要考虑将来的功能扩展。演进的设计推崇尽快地实现，追求快速确定处理方案，快速编码以及快速实现；而方案的设计则需要考虑方案的缜密性，架构的完整性并保证开发过程的有条不紊。 2021年，我翻译了George Fairbanks的著作Just Enough Software Architecture。 Just Enough Software Architecture 书中除了方案式设计和演进式设计之外，还提到了第三种设计：Minimal planned design（最小方案设计），这算是一种中庸之道的选择。书中认为，演进式设计需要与一些灵敏实践协作，包括重构、测试驱动设计与持续集成。George认为方案式设计背后隐蔽的思想是在构造开头之前，制定的方案可以设计出很好的细节。他还提到： 当架构为并行的多个团队所共享时，方案式架构设计就具有实践意义，在子团队开头工作之前，这种方案式设计颇为有效。 书中还写道：（对于多团队开发而言）方案式架构定义了高层的组件与连接器，并与局部的设计相婚配，而子团队则设计这些组件与连接器的内部模型。架构经常会保证全体的不变量与设计决策，例如建立并发策略、连接器的标准集、安排高层职责或定义某些局部的质量属性场景。 最小方案设计，则介乎于演进式设计与方案式设计之间。支持这种设计的人认为：假如完全实行演进式设计，可能会使得设计走向死胡同；而方案式设计又格外难，由于事先对系统并没有全面的了解，可能导致设计错误。在2002年Bill Venners对Martin Fowler的采访中，Martin Fowler认为，最合理的安排是20%的方案式设计，80%的演进式设计。在George的书中，作者认为需要权衡方案式与演进式设计。一种做法是在项目初期进行方案式设计，确保架构能够处理最大的风险。之后，就可以通过局部的设计来应对需求的变化，或者接受演进式设计，通过推行重构、测试驱动设计与持续集成对架构进行演化。 博客coding the architecture上的一篇文章Just enough architecture，从方法学的角度分析如何获得恰如其分的架构。 Just Enough Architecture 文章以及上图所表达出来的含义是：传统的瀑布式实