软件架构的12大陷阱

最近看了一篇由Pierre Pureur和Kurt Bittner的撰写的文章《12个软件架构陷阱及其避免方法》，我觉得这篇文章直击现在的所谓软件架构/架构师的要害，在此写一篇读后感分享给大家。

软件架构的12大陷阱

什么是质量属性需求QARs

这篇文章多处提到了QARs，那什么是QARs呢？质量属性需求（QARs）是指在软件架构中极为重要的一类需求，它们关注的是软件系统的非功能性特征。这些特征包括但不限于系统的性能、安全性、可用性、可靠性和可维护性。与直接描述软件功能的需求不同，QARs更多地影响着软件系统的整体质量和用户体验。例如，一个系统可能功能齐全，但如果它的响应时间很长或者经常出现安全问题，那么这些QARs就没有得到很好的满足。因此，在设计软件架构时，充分理解和有效整合这些质量属性需求对于确保系统的长期成功和可持续性至关重要。

虽然叫《12个软件架构陷阱及其避免方法》，但是文中只给出了11个陷阱，那我们现在一起来看看这12个陷阱分别是什么吧：

陷阱1：不要让一个人主导或左右所有的决定。而是要让适当的团队成员参与决策

• 软件架构的设计需要考虑很多不同的因素和限制，没有一种完美的方案，只能做出一些折中和权衡。
• 如果只让一个人做或影响所有的架构决定，那么架构就会反映这个人的经验、偏见和喜好，可能在某些方面很好，但在其他方面很差。
• 如果让不同的人参与讨论和决策，那么架构就会更全面和平衡，能够暴露和解决团队需要面对的各种权衡。
• 如果让一个人的意见压倒其他人的意见，那么架构就会缺乏团队的支持和认同，可能导致团队的分裂和失败。
• 架构的设计不是多数人的决定，也不是委员会的决定，而是少数有经验和观点的人的决定，通过挑战和验证来达成更好的决定。

陷阱2：不要让复用的目标导致错误的决策，而是要在合理的时候复用代码、组件、设计或配置

• 不要让复用的目标导致不好的决策。相反，只在有意义的时候复用代码、组件、设计或配置。
• 复用代码、组件、设计或配置最初听起来是一个好主意。管理层喜欢推广这个概念，认为它可以降低成本，甚至提高交付速度和质量。一个团队可能决定复用大部分现有的应用程序来更快地交付一个MVP，或者复用一个用来交付一个相当成功的产品的现有架构。
• 当复用的范围是一个函数时，使用服务或类/类型是相当容易和成功的，因为函数的范围很窄，副作用很小，可以在非常不同的上下文中使用。不幸的是，复用的预期收益很少能够实现，至少在架构层面上，因为架构做出了很广泛和基本的假设，很难适应不同的上下文。
• 复用一个现有的架构很少成功，除非新架构的QARs与现有架构设计时的QARs相匹配。过去的表现并不能保证未来的成功！复用现有应用程序的一部分来快速实现一个MVP可能会限制其相关的MVA（最下可行架构），因为它在设计中包含了遗留的技术。为了复用而扩展现有的组件可能会使它们的设计变得复杂，使它们的维护变得更困难和更昂贵。
• 当评估复用的机会时，问问自己是否这样做会使你的架构变得更复杂。如果是的话，你可能更适合自己编写新的代码，以完全满足你的需求。

陷阱3：不要抛弃有经验的架构师，要留住他们并在必要时重新培训他们

• 不要抛弃有经验的架构师。相反，要留住他们并在必要时重新培训他们。
• 管理层痴迷于降低成本，有时受到奖金的刺激，要求经理按一定的百分比减少成本。他们相信软件开发技能是一种商品，可能被低成本供应商的承诺所诱惑，认为他们可以提供与有多年或几十年经验的团队成员相同的技能。
• 有时这是真的。正如一位前同事曾经观察到的，有十年的经验和重复十次一年的经验之间有很大的区别。换句话说，软件开发的真正技能不是编码，或者语法知识，或者对某一套框架的熟悉，而是问题解决。
• 架构工作是问题解决，还需要有一种额外的技能，就是能够根据解决特定类型问题的经验来做出权衡。没有解决过架构问题的开发者会学习，但是他们会在学会之前犯很多错误。雇用或留住已经经历过这个学习周期的人可能比假设你只需要聪明的人，不管他们有没有经验，更便宜。

陷阱4：不要让商业决策左右你的架构，要根据明确的QARs来做出合理的决策

• 不要让商业决策左右你的架构。相反，要根据明确的质量属性需求（QARs）来做出合理的决策。
• 商业决策往往是短期的，而软件架构需要考虑长期的投资回报和系统寿命，所以不能频繁地为了解决某个问题而建立新的系统。
• 市场人士有时候会受到一些新技术的炒作而干涉架构决策，但是新技术并不一定能满足QARs，而且可能带来一些负面的影响。
• 处理架构问题需要有经验，要知道如何提出正确的问题，以及如何设计实验来获得答案。

陷阱5：不要为了快速交付而牺牲质量，要在保持架构可行的水平上管理你的技术债

• MVP和MVA之间总是存在一种紧张关系。MVP的目的是测试一个解决方案是否能改善客户/用户的体验。MVA的目的是确保MVP能够在经济和技术上得到长期的支持。如果MVP没有价值，那么在MVA上的工作就是浪费，但是如果MVA不可行，MVP也就无关紧要了。
• 过分关注MVP的组织可能会发现自己的客户不满意，他们喜欢产品背后的概念，但是对产品的表现感到失望。这就给竞争对手留下了机会，他们可以简单地复制MVP，但是更有效地实现它。所谓的先发优势（最先推出一个解决方案的好处）是被高估的：客户会惩罚那些交付劣质产品的公司。
• 随着敏捷软件开发方法和重构等实践的兴起，一些组织被诱惑认为速度是唯一重要的，因为他们可以随时修复/重构问题。但是实际上，补救工作的有效性是有限的。补救工作，也就是“以后再修”和重构的真正含义，是昂贵的，因为团队必须花费时间弄清楚代码的功能，然后才能用另一种更有效的方式重写它。把它称为重构或使用敏捷软件开发方法并不能从根本上降低工作的复杂性。

陷阱6：不要为了完美你的架构而延迟交付（和反馈），要根据你手头的最佳信息来设计你的架构，并用反馈来改进它

• 软件架构没有完美的，它是由一系列不完美的权衡构成的，其中一些是错误的，但是只有在系统运行时才能发现。有时候甚至在发生一些非常不寻常的情况之前也发现不了。认为架构可以被完美地定义，一劳永逸，是一种危险的心态，它阻碍了团队开发出能够适应未知需求的弹性和可变的架构。
• “事先大规模架构”（“Big Architecture Upfront”）综合征往往是对系统的致命打击。即使不是完全致命，它也不必要地延迟了系统的发布，阻碍了真正的学习。在设计系统之前，不可能确定所有的架构需求。这不是反对创建一个初始的架构；每件事都有一个起点。但是基于你当时拥有的最佳信息来创建初始架构，然后用反馈来改进它，比不断地推迟初始发布，希望得到新的信息，要好得多。
• 还值得注意的是，无论多少次的评审会议都不能替代实际地构建至少一部分架构，并在各种条件下进行测试，以评估其适用性。评审会议，即使是由有经验的架构师主持，也只能发现参与者以前遇到过的问题，而不是那些在使用新的技术或技术时容易出现的新问题。

陷阱7：不要让功能需求驱动架构，要确保它是由现实的QARs来驱动的

• 大家都认为需求是重要的，因此大多数开发团队花费大量的时间来开发满足功能需求的解决方案。处理功能需求相对简单，因为业务利益相关者通常能够清楚地表达他们想要什么，而他们很难表达质量属性需求。
• 不幸的是，好的架构设计是由明确的质量属性需求来驱动的，而只使用功能需求来设计软件架构会创建一个可能无法很好地扩展、负载或持久的软件产品。如果一个开发团队只关注功能需求，那么它的解决方案的架构很可能无法满足用户的真实需求。

陷阱8：不要盲目模仿别人的成功架构，要根据自己的QARs来设计自己的架构

• 一些流行的文章和会议演讲介绍了一些著名的公司或供应商是如何使用特定的方法来满足特定的QAR的。这些演讲和文章分享了一些重要的见解，是学习的重要来源，但是它们也有局限性。同样的道理也适用于所谓的“最佳实践”或“架构模式”。知道别人使用某种方法取得了成功是有用的，但是只能到一定程度。
• 每个架构都是在不同的力量之间的平衡，是一组在其上下文中有意义但是通常不适用于其他上下文的次优的权衡。理解自己的解决方案所涉及的力量和可能的权衡是必要的，因为它们可能会让你得出与会议上的著名公司不同的结论……而你们都是对的。
• 要理解别人的选择，你必须了解他们的上下文和QARs。只知道他们做出的最终选择并不能告诉你太多。如果你只根据他们的选择而不了解他们的上下文来做决定，可能会让你走向失败而不是复制他们的成功。

陷阱9：不要让供应商或顾问为你做架构决定，要确保你对你的架构保持控制

• 盲目地依赖供应商或顾问的架构方案是一种模仿别人的架构的变形。他们的方案可能在其他的上下文中有效，但是你仍然需要自己评估他们的提供或建议。他们的方案可能完全适合你的情况，但是如果不是，那么你自己要负责解决问题，而不是他们。从一开始就理解这一点，有助于你提出更好的问题，做出更好的决策。
• 顾问可以为你的组织带来急需的专业知识和不同的视角，但是他们并不是无所不知，他们也有盲点。他们可以在你的决策中给你建议，但是他们不能替你做决定。
• 使用开源框架而不了解它们的QARs、安全漏洞、维护问题和许可问题，实际上是另一种外包决策的方式。开源组件是任何现代应用的重要部分，但是它们可能支持或不支持你的QARs。在你采用它们之前，你需要了解它们的创建者做出了什么决定，以及这些决定是否适合你。

陷阱10：不要过度泛化架构，要根据你的QARs来设计你的架构，并且只考虑你自己的QARs

• 软件架构不是通用的；它们反映了依赖于上下文和应用的权衡。一个软件架构只要满足它的QARs就是好的。
• 有时候，这种感觉是不够的，觉得存在一个更通用的解决方案，可以解决更大范围的QARs，提供一个跨不同类型应用的通用架构。但是，解决一个更通用的问题并没有额外的好处，也没有证据表明这样的通用架构是必要的或者会被使用。许多行业标准的第二次修订（人月神话，第二系统效应）就陷入了这个陷阱，试图满足任何可能出现的需求，而在这个过程中变得臃肿而无用。

陷阱11：不要一次性建立架构，要分步骤地建立和测试架构，以降低风险和浪费

• 软件架构也是软件；要知道它是否达到目标，就必须先有目标，然后至少建立部分架构并检查是否朝着目标前进。
• 软件架构的目标是满足它的QARs。或者至少做出合理的选择，使大部分QARs得到满意的满足，因为不可能完美地满足所有QARs。架构的技巧在于平衡权衡。
• 当“事先规划好的架构”方法失败时，是因为团队需要做出权衡的信息只能通过建立和测试部分架构才能获得。无论团队成员有多聪明或技术经验丰富，架构可能都要处理他们以前从未见过的事情。因此，他们需要实验。
• 这并不意味着架构同行评审不重要，尤其是当同行（团队之外的人）可能有一些经验可以为团队节省很多工作时。或者至少指出一个可能有成果的探索方向。因为“我们没有时间做这个，如果我们想要按时交付”而跳过架构同行评审通常是目光短浅的，可能导致以后更多的返工。

结语

我们很难明确地说出什么会导致软件架构的成功，但我们可以轻易地指出哪些做法会导致失败。

依赖他人定义你的软件架构或复制别人的架构是导致失败的重要原因。不考虑自己的（QARs）或期待供应商的技术或流程来解决问题，也是常见的失败原因。