前言
- 软件开发人员通常对架构实践持怀疑态度，并倾向于避免有意识地进行架构设计活动，而更倾向于由自组织团队形成的架构设计；
- 有意识地聚焦于架构是必要的，以解决新兴架构的局限性，并满足初始的质量属性需求；
- 软件架构受到质量属性需求（QAR）的驱动，如果在最初的迭代中不考虑它们，那么在软件系统超出最初的试点阶段并具有较少用户时，往往会出现问题；
- 增强开发者的隐式架构决策意识，并强制将这些决策明确化，可以帮助开发团队更好地、更理性地利用从其迭代中获得的经验数据做出决策；
- 重构和过度组件化可能导致对解决方案的片段化视图，因此没有人对发生的情况有完整的理解；
- 现代架构实践，如持续架构和演进式架构，为使架构决策更加明确提供了工具，使开发人员能够提供更具可持续性的软件产品。
许多软件开发人员对架构实践持怀疑态度，他们将这些实践与僵化和繁琐的流程以及大量的前期规划和设计联系在一起。
因此他们认为，如果他们遵循这些实践，可能需要很长时间才能最终交付一些（甚至可能并不是）客户想要的东西。
他们更愿意专注于了解客户的需求，并使用由小而快的迭代组成的敏捷流程来交付。
遵循这些流程的一些人认为，架构将“自然而然地”形成，而不需要有意识的规划或架构聚焦。因为这些信念，他们可能不认为软件架构很重要，甚至可能不关心它。
自然形成的架构方法通常可以提供客户最初需要的功能，这是一个良好的开始。
但是，如果没有明确关注产品的可持续性，它有可能在达到预期退役之前就开始衰败，导致产品无法维护。
通过专注于关键的质量属性，如性能、可扩展性、安全性和弹性，有意识地进行软件架构可以帮助延长产品的寿命，使其在较长时间内可持续发展。
图1比较了物理世界中的前期设计和自然形成的设计方法。
图1：比较前期设计和自然形成的设计方法
前期设计方法在我们做的事情非常熟悉并且已经做过很多次时效果很好。例如建造摩天大楼、挖掘运河、制造产品或建造桥梁。在这些情况下，我们可以应用“最佳实践”，依靠过去的经验。
但是，在处理全新事物、我们不太了解的事物或变化非常快而“最佳实践”尚不存在的情况下，前期设计就不起作用了。在这种情况下，受控的实验，即科学革命的基础，可以帮助我们寻求对问题和可能解决方案的更深入的理解。由此产生的解决方案是“自然形成”的，但是是通过有意识的实验路径指导的。
这两种方法都有价值，但是在非常不同的情况下，一个是处理大部分已知的事物，另一个是在不断变化的世界中探索新的机遇和可能性。
严格自然形成方法的问题在于，受控实验可能不会在合理的时间内产生可持续的解决方案，并且需要接受可以接受的重做量。软件架构实践可以通过提早提出更好的问题来引导实验，从而降低交付可持续产品的时间和成本，同时仍然享受敏捷方法的好处。
架构体现在哪
正如我们在之前的文章软件架构：可能和你想的不太一样软件架构：可能和你想的不太一样中讨论的那样，架构的本质包括定义和约束产品技术方面的一系列决策。这些决策无论团队采用哪种方法，以及他们是否有意识地或默默地做出这些决策，都存在。这些决策关注产品如何满足质量属性需求或QAR。
质量属性需求(QAR)也可以是显式的或隐式的，尽管对它们做出明确的说明会使它们更容易被解决，以确保产品满足它们。例如，用户通常希望在使用产品时能够获得响应，而不管有多少其他人也在使用该产品。明确说明“响应性”的含义，以及产品可以支持多少并发用户而不会变得“无响应”，将有助于开发团队更好地决定他们的技术方案；而像“系统必须快速”或“系统必须可扩展”这样的陈述并不能帮助团队做出更好的技术决策。
评估质量属性需求并设计架构以实现这些需求涉及一定程度的前期规划，这是软件系统成功的关键驱动因素，原因如下：
- 软件架构受到QAR的驱动，在最初的迭代中不考虑它们往往会在将软件系统部署到超出最初试验阶段并具有少量用户的情况下引发问题。因此，当必须满足关键的质量属性需求（如性能、安全性或可扩展性）时，可能需要进行重大的架构、设计和代码重构，这可能会导致软件架构具有较高的波动性。此外，如果架构设计未能强化组件的抽象和隔离，重构的成本可能会激增。
- 有意识地聚焦于架构是必要的，以解决新兴架构的局限性，并满足初始的质量属性需求。例如，在初始架构设计中纳入一个简单的监控框架对于确保软件系统具有弹性并如预期地执行至关重要，除了提供有关系统实际使用情况的有用信息外，还提供了有关其架构设计的反馈循环。
- 重构和过度组件化可能导致对解决方案的片段化视图，因此没有人对发生的情况有完整的理解。可能缺乏意识到正在使用哪个版本的组件，以及每个组件的服务级别协议（SLA）可能未经记录。每个服务使用单独的数据存储的微服务架构可能会导致数据一致性问题。另一方面，局势架构解决方案在可持续性上存在问题，但内部一致性高。这两种方法各有优缺点。
你的软件系统是可持续的吗
广义上说，实现“可持续性”是软件产品架构工作的重点。如果一个软件产品能够满足其当前的需求，包括QAR，而不危及其满足未来需求的能力，那么它就可以被认为是可持续的。正如我们在前面的部分中所述，质量属性需求驱动着架构，满足关键的QAR对于创建可持续的架构设计至关重要。不幸的是，随着功能增强的实施以及新的设计决策的制定，软件系统随着时间的推移会“磨损”，这可能会拉伸甚至打破原始的架构设计。导致“磨损”的常见原因包括：
- 原始设计决策因缺乏知识或理解而被淘汰。与“磨损”系统的设计相关的决策和假设很少能够准确地记录下来。当没有人再提出或回答问题时，软件系统开始衰退。提出问题是评估软件系统健康状况的重要技术，前提是有知识渊博的资源可以回答这些问题。
- 技术债务或经济成本接近不再可行的程度，无法实现新功能。
- 假设通过对复制的代码进行微小更改即可实现新功能，开发人员会试图在不同组件中重用现有代码块。遗憾的是，他们可能没有完全理解原始代码所依赖的架构背景，而在不同组件中重用该代码可能会在后期产生不希望的副作用，如性能、可扩展性或可用性问题。这些软件变更增加了技术债务，并降低了系统的整体质量，除非能够迅速解决技术债务。
- 技术的演进导致软件系统在其未设计的技术平台上运行。一些较老的软件系统经历了“灾难性的成功”，因为它们的寿命远远超出了最初的计划，它们的技术债务已经非常高且非常难以“偿还”。偿还这笔技术债务的成本可能（甚至已经）超过完全替换该软件系统的成本。
- 假设的失败。系统性的逻辑体系，包括软件系统，在假设失败时最终会崩溃，而软件开发人员可能不会意识到他们所做的假设。隐藏的假设可以被视为对系统的限制。清晰地表达所有假设并保持这些信息的及时性非常重要。质量属性需求本身就是需要验证的假设，其实现需要进行经验测试和确认，如果可能的话，要使用自动化。性能、可扩展性、弹性（例如使用类似Netflix的“猴子军队”的方法）和安全性是很好的例子。质量属性的自动化测试的目标是持续测试假设（例如，QAR是否仍然现实？），并指导软件系统的演变。
- 软件系统在没有考虑或理解原始架构的情况下故意添加功能而失去其架构完整性（我们可能称之为“架构熵定律”）。因此，它们可能不再具有可持续性。
评估软件架构适用性
如何知道您的软件系统正在磨损，就像您知道汽车轮胎磨损并需要更换一样？就像医生可能使用许多不同种类的工具来评估个体的健康状况（心电图、磁共振成像、CT扫描、血液检测、体格检查），不同的工具有助于团队评估软件架构的适应性。较老的系统可能难以理解，因为正如我们之前提到的，它们的设计决策和假设通常没有记录下来，而且文档，即使存在，也很可能已经过时。理解和评估它们的架构设计通常需要“软件考古学”工具和技能。总的来说，有许多可用的工具来评估软件架构的适应性，包括：
- 架构审查（尤其是同行审查）是评估软件系统架构设计适应性的有效工具，尤其是如果它们侧重于权衡（例如，CMU/SEI的“架构权衡评估方法”）。
- 自动化软件质量评估工具（例如CAST），但需要人们接受结果。
- 代码审查（尤其是自动化代码审查）非常有用，可以确保代码质量。成对编程是实现此目标的另一种方法。
- 适应性函数实现，例如自动化性能测试。
- 仪器化框架实现，包括Web服务监控工具，以提供软件架构的反馈循环。
- 技术债务识别和评估，包括标记增加技术债务的决策。
- 自动化测试工具（尤其是负载/扩展/弹性测试）。
- 缺陷趋势分析（这是技术债务的代理），需要在一致的方式下捕获数据。目标是寻找不稳定性增加的迹象。
- 生产事故趋势分析 - 与缺陷趋势分析的要求和目标相同。
- 安全测试工具。使用这些工具的目标是寻找风险暴露。
总结
在长达二十年的“大量预先设计”与敏捷实践之间的冲突中，软件开发人员一直在努力寻找这两种方法之间的有意义的折衷方案，并倾向于避开有意识的架构重点活动，而更多地采用从自组织团队中涌现出的架构设计。因此，他们经常认为软件架构并不那么重要。对他们正在做出的隐含决策有更深的认识，并迫使这些决策被明确地做出，可以帮助开发团队更好地利用他们从迭代中获得的经验数据，做出更加明智、更加知情的决策。现代架构实践，如持续架构和进化架构，为使架构决策更加明确提供了工具，使开发人员能够交付更具可持续性的软件产品。