创作者 | Pierre Pureur, Kurt Bittner

译员 | 明知道山

方案策划 | 丁晓昀

很多手机软件开发者不信任架构实践活动，她们将这类实践活动与严苛和蛮横的流程及其主要的早期策划和设计方案联络在一起。

因而，她们坚信，假如她们遵循这种实践活动，很有可能要很长期才可以交货一些乃至很有可能并不是顾客需要的物品。

她们更想要致力于了解用户的要求，并利用小而迅速的敏捷优化全过程来交货商品。

她们中有一些人坚信，只需遵循了那些全过程，架构当然会“发生”，而不用有目的地开展方案或架构设计方案。由于存有这种信仰，她们也许不觉得手机软件架构是主要的，乃至有可能不关注它。

这类架构方式 通常可以交货达到顾客需要的商品，这是一个新的开始。

可是，如果不显式考虑到商品的可持续，它也有很有可能衰落，造成设备在当然退伍前没法维护保养。

根据关心重要的品质属性，如特性、可扩展性、安全系数和延展性，有目的的手机软件架构方式 有利于增加设备的生命期，使其在更久的时间内可持续性。

事先架构和应急架构比照

如果我们已经做的事儿是大家十分熟悉的，而且已经做了很多次了，那麼事先设计方法就很合理。例如，修建摩天大厦、挖大运河、生产制造设备或修建公路桥梁。我们可以运用“最佳实践”，并依靠以往已经在这类事儿上检验过的合理方式 。

如果我们已经解决一些物品是新一代的，而且大家不太掌握，或是转变太快以致于都还没“最佳实践”，那麼事先设计方案就失灵了。在这样的情况下，做为科技革命基本的可操控性试验可以协助大家更进一步地了解问题和有可能的解决方法。最后的解决方法“发生”了，仅仅它顺着有目的的实验操作的途径向大家挥手。

这二种方式 是有價值的，但适用的场面十分不一样，一种可用来解决绝大多数已经知道的事儿，而另一种可用来在改变的全球中探寻新的可能和概率。

第二种方式的问题取决于，可操控性试验很有可能没法在有效的時间内造成可持续发展的解决方法，而且很有可能要开展可接纳的返工。手机软件架构实践活动可以根据很早地明确提出更强的问题来具体指导试验，以降低交货可持续性商品的时长和成本费，并依然可以保存灵巧方式 的优点。

架构是怎么发生的

正如我们在前一篇文章中所探讨的，架构的实质由一组界定和管束商品技术面的决策构成。无论精英团队选用哪一种方式 ，无论它们是有目的地或是心知肚明地作出决策，这种决策全是普遍存在的。这种决策致力于商品如何处理品质属性要求（QAR）。

QAR 还可以是显式或隐式的，虽然显式的更易于解决并可以保证商品切合他们。例如，客户通常期待在应用商品时可以获得立即回应，而无论有几个也在应用该商品。显式地申明“回应性”要求及其商品可以适用是多少高并发客户而并不会变为“没法应式”的，将有利于开发设计精英团队对她们的工艺方式 作出更快的决策，例如“系统软件的效率务必贼快”或“系统软件务必是可伸缩式的”那样的申明并无法协助精英团队作出更快的技术性决策。

评定品质属性要求和设计一个架构来完成这种要求牵涉到一些早期整体规划，这种也是软件系统获得成功的重要推动要素，缘故如下所示：

手机软件架构是由品质属性要求推动的，假如在起初的优化中沒有充分考虑他们，通常会在软件系统被构建到原始实验环节以后（仅有少许的客户）发生问题。因而，当务必达到重要的品质属性要求 (如特性、安全系数或可扩展性) 时，很有可能要开展关键的架构、设计方案和代码优化，这也许会产生具备相对高度多变性的手机软件架构。除此之外，假如架构设计方案沒有强大地完成部件的抽象性和防护，重新构建的费用也许会飙涨。

为处理应急架构的片面性和达到最开始的品质属性要求，开展有目的的架构设计方案是需要的。例如，除开给予有关系统软件具体运用状况的实用信息内容及其有关架构设计方案的反应控制回路以外，在原始架构设计方案中添加一个简便的监管架构，这针对保证软件系统的延展性和准确性而言是极为重要的。

重新构建和过多的组件化会造成解决方法的泛娱乐化，以致于没人能彻底了解发生什么事。有可能不清楚已经应用的部件是啥版本号，也很有可能沒有纪录每一个模块的服务水平协议书 (Service Level agreement，SLA)。微服务架构架构为每一个服务项目应用了独自的数据储存，这也许会致使数据信息一致性问题。单个系统软件的可持续较弱，但具备极度的内部结构一致性。这二种架构都各有优点和缺点。

你的软件系统是可持续性的吗?

广义地说，完成“可持续”是软件项目架构工作中的关键。假如软件项目可以符合当下要求 (包含 QAR)，而不危害达到以后要求的工作能力，则可以觉得该软件项目是可持续性的。正如我们在前一节中上述，品质属性要求推动了架构，达到重要 QAR 针对建立可持续性的架构设计方案而言是极为重要的。遗憾的是，伴随着功能增强的建立和新设计方案决策的制订，软件系统会伴随時间的变化而“损坏”，这也许会延伸乃至毁坏最开始的架构设计方案。普遍的“损坏”缘故包含：

因为维护保养操作系统的开发者系统对欠缺了解，最开始的设计方案决策也就落伍了。与系统开发有关的决策和假定非常少会被精准地记下来。当大家不会再对于系统软件提问问题或回答时，软件系统就逐渐衰落了。提问问题是评定软件系统身体状况的一种关键技术性，如果有专业知识网络资源可以回应这种问题得话。

技术性负债的积累会造成服务器维护不会再行得通或不会再具备成本效益，而且没法完成新的作用。

开发者尝试器重不一样部件的代码块，她们觉得可以根据对重复使用编码开展细微的修改来完成新作用。缺憾的是，她们有可能不能彻底了解初始编码所依靠的架构前后文，也观念不上在不一样的部件中器重编码很有可能会在之后发生多余的不良反应，例如特性、可扩展性或易用性问题。这种手机软件变动提升了技术性负债，并减少了操作系统的总体品质，除非是技术性负债可以快速获得处理。

技术性的进步造成一些软件系统运作在并不是为他们设计方案的技术性服务平台上。一些较老的软件系统经历了“毁灭性的取得成功”，由于他们不断出现的时长比起初方案的要看起来多，并且他们的技术性负债已经显得十分厚重、解决不了且成本极大，“还款”下去十分艰难。还款技术性负债的费用很有可能与彻底更换该软件系统的成本费相近，乃至有过之而无不及。

不成功的假定。逻辑性的行为主体，包含软件系统，最后会由于假定的错误而奔溃，手机软件开发者很有可能没意识到她们所做的假定。掩藏的假定可以被觉得是系统的管束。重点在于要清晰地表明全部的假定，并维持数据的升级。品质属性要求自身也是一种必须开展认证的假定，他们的完成必须通过工作经验的测验和确定，假如有可能得话，可以应用自动化技术。特性、可扩展性、延展性 (例如，应用类似 Netflix 猴子军团的架构) 和安全全是不错的事例。品质属性功能测试的总体目标是不断对假定 (例如，完成 QAR 依然是实际的吗？) 开展检测，并用于具体指导软件系统的演变。

假如对起初的架构沒有有效的了解，即使提升了新特点 (我们可以称作“架构熵定律”)，应用应急架构建立的软件系统最后也会丧失架构完好性。因而，他们很有可能不会是可持续性的。

评定手机软件架构的适用范围

如何知道你的软件系统何时损坏了，如同了解你的轮胎何时损坏了并必须拆换一样？如同医师很有可能应用很多不一样品种的设备来评定个人的身体状况 (心电图检查、MRI、CT、血夜检测、全身体格检查) 一样，不一样的道具可以协助精英团队评定手机软件架构的适用范围。旧的操作系统很有可能难以理解，由于正如咱们之前提及的，他们的设计方案决策和假定通常沒有文本文档纪录，而即使存有文本文档，也很可能是淘汰的。了解和分析体系的架构设计方案通常必须“手机软件考古学”专用工具和专业技能。总体来说，有很多软件可以用于评定手机软件架构的适用范围，包含：

架构审查 (尤其是对等审查) 是评定软件系统架构设计方案适用范围的高效专用工具，尤其是假如她们关心的衡量 (例如，来源于 CMU/SEI 的架构衡量评价方法 (pdf))。

自动化技术的系统品质评定专用工具 (例如 CAST)，可是大家必须接纳他们形成的结论。

编码审查 (尤其是自动化技术编码审查) 针对保证编码品质而言十分关键。结对编程是完成这一目的的另一种方式 。

适用男性性功能完成，例如自动化技术性能指标。

提高架构完成，包含 Web 服务项目监管专用工具，为手机软件架构给予意见反馈循环系统。

技术性负债的鉴别和评定，包含标出会造成技术性负债提升的决策。

自动化技术检测工具 (尤其是负荷 / 弹性 / 延展性检测)。

缺点变化趋势 (这也是技术性负债的代理商)，必须应用一致的方法捕获数据信息，总体目标是鉴别多变性。

生产制造安全事故变化趋势——与缺点变化趋势具备同样的标准和总体目标。

安全性检测工具。应用那些道具的目的性是找到风险暴露点。

结 论

在“早期大家装”和灵巧实践活动中间长达 20 年的争论中，手机软件开发者勤奋在这里二种方式 中间寻找一个令人难忘的均衡点，并从有目的的架构主题活动转为生态系统理论精英团队的架构设计方案。因而，她们经常觉得手机软件架构并非那麼关键。大量地意识到架构之中存有的隐式决策，并驱使这种决策变为显式的，这有利于开发设计精英团队运用她们从 Sprint 和优化中得到的工作经验数据信息作出更强、更聪明的决策。当代架构实践活动，如不断架构和演变架构，给予了可以协助作出显式架构决策的专用工具，让开发者可以交货更可持续发展的软件项目。

某系其他信息，请参照 Murat Erder、Pierre Pureur 和 Eoin Woods 共同编撰的的“Continuous Architecture in Practice”，及其 Murat Erder 和 Pierre Pureur 共同编撰的的“Continuous Architecture: Sustainable Architecture in an Agile and Cloud-Centric World”。

作者介绍:

Pierre Pureur是一位认真负责的手机软件架构师，有着普遍的自主创新和应用程序开发环境，丰富多彩的金融信息服务领域工作经验，普遍的资询工作经验和全方位的技术性基础设施建设专业知识。他曾出任一家大中型金融投资公司的总裁公司架构师，领导干部大中型架构精英团队，管理方法大中型高并发应用开发新项目，具体指导创新活动，及其制订发展战略和业务流程方案。他是“Continuous Architecture in Practice: Scalable Software Architecture in the Age of Agility and DevOps”(2021 年出版发行) 和“Continuous Architecture: Sustainable Architecture in an Agile and Cloud-Centric World”(2015 年出版) 的合著者，并发表了许多文章，还在多个软件架构会议上做演讲。

Kurt Bittner拥有超过 30 年在短反馈驱动周期内开发软件的经验。他帮助许多组织采用敏捷软件交付实践，包括大型银行、保险、制造和零售组织，以及大型政府机构。他曾为包括 Oracle、HP、IBM 和微软在内的大型软件交付组织工作，曾是 Forrester Research 的技术行业分析师。他的工作重心是帮助企业建立强大的、自组织的、高性能的团队，为客户提供他们喜爱的解决方案。他写了四本关于软件开发的书，包括“The Nexus Framework for Scaling Scrum”。他现居科罗拉多州博尔德市，担任 Scrum.org 的企业解决方案副总裁。

https://www.infoq.com/articles/care-about-architecture/?