|
2019年8月，国内出版了[美] 尼尔 · 福特 / [美] 丽贝卡 · 帕森斯 / [澳] 帕特里克 · 柯撰写的《演进式架构》一书，英文版在2017年10月出版。 对演进式架构有如下这样的关键说法：An evolutionary architecture supports incremental, guided change as a first principle across multiple dimensions. 大体翻译为“演进式架构支持增量式并且引导式的变更，把它作为跨多维度的第一原则。“ 此书识别了如下3个要素：
本文第1版虽然写在《演进式架构》一书之前，但正好与此书契合，本文描述重点在于演进，通过以下方面来说明“演进”的架构。
架构的范围架构这词起源于建筑领域，被延伸使用到了包括软件领域的其它诸多领域。现在只看软件领域，就存在了许多种架构。我们常常会遇到不同形式的架构说法，比如企业架构、系统架构、信息架构、应用架构、实现架构、基础设施架构等。几乎每种类型的架构都圈了所覆盖的架构范围，而且都有扩大“地盘”的冲动。眼下，软件业界并没有相互形式间的协定，导致对软件架构同一词语的不同理解。软件架构考虑的范围随着不同项目、不同团队、不同系统，甚至于不同的时间段而不同。 对比原来常用的基本设计和详细设计，架构一般不包含传统的“详细设计”，也不完全包含“基本设计”，而更加接近于“High Level Design”。一般而言。架构范围不包括需求细节、用户交互细节、类的细节。 因此，对于特定团队考虑进行架构时，值得首先就架构的范围进行讨论，并达成初步的共识。当然架构范围并不是从第一次达成共识后就不再变化，在架构演进时，团队能够就架构范围进行调整。 架构的范围并没有标准答案，以下是对于架构考虑范围的推荐，最推荐的给5颗星，其次4、3、2。
初次架构在系统早期，比方某系统的第0次迭代，或者重大升级，新接手某系统，需要进行初次架构，需要理解系统的现状、范围、特征。 在架构关注的范围内，哪些因素是硬性限制条件？哪些因素是可变限制条件？哪些因素是需要考虑解决的问题？ 一般地，全新开发系统的限制条件比較少，需要考虑解决的问题比较多，往往面临“艰难的选择”，当然这也是体现架构价值的地方。 所开发的系统将或者已经存在于环境中，那么其环境必定影响架构，所以需要考虑 “环境中的架构”。基本上，环境决定了系统执行的范围，这些又约定和限制了架构。影响架构的环境因素包括架构所支持的商务环境，系统涉众群，内部技术限制（比如须要符合组织标准）。和外部技术限制（比如对外部系统的接口或遵守外部规则的标准）。 在此期间，鼓励召开架构的头脑风暴会议，讨论系统的功能、性能等等特征，并思考实现这些特征的高层设计策略，甄别可行地技术策略。 依据这些了解、讨论和思考，形成初始的架构文档。 特别再次值得反复说明的是：多数的架构是在已有软件或系统上进行的。原有软件或系统将带来原有的架构，这并不意味着新项目能够不再考虑架构。原有的架构可能不再适应当前的情况，而恰恰是须要改进的地方。原有的架构或许非常好，不必改动，新开发仅仅须要在其指定的架构下按部进行就可以。原有的架构总体可行，局部需要调整，这样的判断本身就是架构。 架构文档在起草初始的架构文档时，值得充分理解并复用原有架构方面的文档。 不管利用原有文档，还是新写，应当形成一套架构文档，说明团队架构范围内所关注的内容。这一套架构文档要得到配置管理。 这套架构文档的典型组成 1， 核心架构文档（必需） 2， 接口文档（对外接口，必需） 3。 模块或子系统架构（可选） 4， 其他补充说明（可选） 在迭代进行中，架构文档应当始终保持是一套文件，这套文件随着种种新情况、变更而得到演进。但始终保持其全局性和及时性。 最值得注意的地方是要避免出现把新增改动的内容写入特定版本号的架构文档，这样会导致组合多个文件才干反映架构总体情况。详细而言，避免以下情况： 假设在第2个迭代结束后已经 形成了 ABC架构文档，在第3个迭代时，当中某部分有重要改动。 团队为了明白这些是第3迭代的任务。也为方便的阅读第3迭代的架构，把这部分改动另写为ABC第3迭代架构文件。在第4个迭代时。又有某部分须要新增改动，然后有出现了ABC第4迭代架构文件，依此类推。到第10个迭代时，须要阅读全部前面的架构文件才干了解全局，而不再有一份核心架构文档就能反映全局。短期迭代的方便处理将损害长期的架构演进。 因此。演进的架构必须利用版本控制工具，以前推荐了诸如CVS，SVN，ClearCase等来管理架构文档，最新推荐带有自动版本记录的线上化工具，比如Confluence，腾讯文档等等。线上化工具支持多人线上协同，使用效率远远超过了把word文件存放到Git。 通过这类工具的帮助，在不论什么时间点，都能及时地展现的一套架构文档，也能追随到老版本，还能比对前后差异。为增量式演进提供了巨大便利，或者说这是增量式演进所必需的。 迭代中的架构在迭代开发当中，在每一个迭代的前期甚至提前一个迭代，结合最新业务需要来考虑对于架构的影响。 如果对于原有架构文档有变化，就应当修订架构文档。在演进中，对于架构最常见的两大影响是 1，模块的改动和新增，包括外接新系统； 2，因为时间推移所带来的容量方面的问题，一般最突出的是性能问题。值得密切注意模块之间的交互。 推荐提问：
另外可能的变化是团队对于架构范围的理解可能变化，依据变化后的架构范围理解，增补架构文档的内容。 值得再强调的是迭代中不仅仅可以对架构范围进行调整，也可以对之前的架构决策进行调整，这就是演进，而不是如同建筑的架构不可调整。 还有一个因素值得强调-迭代的颗粒度，哪怕采用长达4周的迭代，对比原来基本设计+详细设计做法对应的时间颗粒度，也是有几倍的差距。原来讲究基本设计+详细设计的情况下，对应交付版本间隔长达4个月以上，甚至更久。 当下常见的迭代长度是2到3周，领先企业有采用1周迭代周期，也有无迭代做法，交付版本间隔常见也在2到3周，领先企业更加快。 在这样情况下，有一个形象的比喻是给行驶中的汽车换个轮子，不会再有安排一个长达3周的设计阶段来做设计。 因此原来基本设计+详细设计的做法不能简单放入短迭代开发，需要经过裁剪后才能很好的指导迭代开发。 推迟决策的架构在演进的架构中值得推迟决策，推迟决策并非指到最后才决定做什么，而是要尽量推迟决策，以更灵活的应对不确定性。 当出现架构决策时，考虑例如以下提问：
在演进的架构下，也为决策的推迟提供了便利。当前迭代涉及的架构问题是须要立即给出方案的，对于兴许的架构问题是有机会推迟决策的。当然这里是有长期考虑和短期考虑的权衡，并非说演进的架构下仅仅须要考虑本迭代的架构问题。但也不是说须要考虑全部兴许迭代的架构问题。 对比传统架构设计，往往假设架构有长时间指导意义，比较稳定，因此需要慎重，花费专门大段时间来进行架构设计。 在延迟决策的架构策略下，恰恰得到相反的论断：在刚刚开始时，没有必要安排超过迭代周期的、专门的架构设计阶段或迭代。在演进的背景下，预先花费大量时间的所谓设计阶段是多余的。 因为这个世界变化太快，提早的架构往往想得太美，不如采用演进的做法，在迭代增量当中逐渐追求并且逼近完美。 另外值得说明的一点是推迟决策不是等到代码写得差不多了，再来补架构设计文档！如果是代码写得差不多了，那只能是为了文档合规要求而写文档，丧失了架构设计的意义。架构应当在前面指导代码编写，也敢于留出空白让一线程序员发挥。 ---全文玩--- |
|
|
