ThoughtWorks CTO：2025 年之前，我们会看到架构的演进，但不会看到革命
在QCon伦敦会议的第二天，ThoughtWorks 的 CTORebecca Parsons重新审视了演进式架构（evolutionary architecture）的理念并设想了在2025年前它将会出现的变化。她从演进式架构的定义开始，回顾了每项“能力”和属性，预测了在下一个阶段将会发生的变化。她的结论是，我们会看到演进，但不会看到革命。
演进式架构支持在多个维度上有指导性的、渐进式的变化。
Parsons 解释了为何采用演进这个词而不是敏捷或涌现。在与“演进式架构”一书的合著者 Neil Ford 进行了一次建设性、强有力的对话后，这个名字被确定了下来。最初，Ford 将这种做法称为“涌现式（emergent）”架构。虽然在代码方面，“好”与“坏”相对比较容易达成一致，但在架构方面就并非如此了。定义的指南部分指出了好的架构要有哪些部分组成。
这就是我们引入适应度函数（fitness function）的原因。适应度函数是一个特定的系统在多大程度上反映所需的行为特征的客观描述。
随后，Parsons 着重强调了可执行的重要性：在通往生产化的道路上，如何渐进式地增加新的特性并提供可行的机制？
这些适应度函数应该被纳入到部署流水线中。
定义的最后一部分强调的是多维度方面。她使用一张幻灯片展示了几年前维基百科上的“能力（-ilities）”列表。这个列表后来有了一些变化，例如，更加注重可观测性。列表中的一个谬误是，我们无法最大化所有的能力，因为其中有些能力是互斥的：“有些系统是一次性的，不关心可演进性”。
接下来，Parsons 谈到了如今演进式架构的原则，并预测了它们在未来两年的发展。
个人认为，我们第一次尝试 SOA 的失败原因之一就是我们在系统周围画了边界。比我们围绕概念画出的边界更多。
最后的责任时刻：为了尽可能多地掌握系统的信息，我们想把决定推迟到最后的责任时刻（responsible moment）。需要做的权衡转换成了“能力”和适应度函数。
为可演进性而设计和开发：如果可演进性对你的系统很重要，那么它不仅对你如何编写代码很重要，而且对你如何结构化代码也很重要。
可读性是关键，这就是优质软件指标的作用所在。[…]这就是我们谈论边界、耦合和内聚的时候。
Postel 定律：对收到的东西要慷慨，对发送的东西要谨慎。
如果你只需要一个邮政编码，就不要验证收到的地址。这样，如果我决定把它分成两行，你就不需要在意它了。
可测试性架构：测试某项功能的能力以及某项功能的可测试性如何，很好地说明了你的边界划分是否合理。如果你专注于测试金字塔的所有层次，你就会有更好的系统架构。
康威定律：可怕的人的问题。任何系统都会反映出所有组织的沟通情况。
如果你想要一个三阶段的流水线，你必定有三个小组。
最后，她谈到了这些原则在未来两年内会受到怎样的影响。根据 Parsons 的说法，“最后的责任时刻”和 Postel 定律都不会受到影响。
即使这些原则保持不变，但会有更多的创新，从而能够建立起更强大、更具“免疫性”的系统。不仅仅物联网、增强或虚拟现实等系统的复杂性中会融入创新，更多的创新将发生在机器学习模型的测试方式上。人工智能辅助开发会促进不同类型的开发技术的发展，如测试优先开发（Test First Development），即开发人员编写测试，人工智能生成代码，或其他方式。
所有这些都将通过增强持续部署流水线、增加对生产中测试的依赖以及扩大适应度函数和方法套件来实现。
她在演讲结束时这样总结说：
这些原则自始至终都是不变的，目前还没有迹象表明我们遗漏了什么原则。实践会不断发展，但不会有根本性的改变[……]即使创新会改变工具，但原则是不变的。演进式架构会继续发展，但不太可能会迎来一场革命。
原文链接：
Rebecca Parsons – ThoughtWorks CTO: By 2025 We’ll See Evolution in Architecture, But Not Revolution
本文文字及图片出自 InfoQ
你也许感兴趣的：
- 苏宁易购移动架构演进的青铜时代、白银时代和黄金时代
- 撇开代码不说，谈谈我对架构的6个冷思考
- WEB前端MVC架构变形记
- Tomcat 架构探索
- 如何为你的开源项目选择正确的品牌架构
- 我理解的架构师
- 在首席架构师眼里，架构的本质是……
- PHP系统设计与云架构
- 具有魔法的 H.264
- 多用户环境中的 rootless Docker
你对本文的反应是：