第一、主要理念：

• 那些没有直接参与架构建设的人不宜作出架构相关决策。只有当人们深刻理解了架构的建设过程，他们才有资格做出关键的技术判断。

• 架构设计的驱动力来自于质量属性需求（QARs）。对这些需求的忽视或不明确定义可能会导致项目的不成功。

• 应避免仅仅依赖供应商的建议来制定架构设计。供应商可能对你的特定需求和QARs缺乏深入理解，并且不应该为你做出关键决策。

• 不应仅因为其他组织的架构看起来成功就盲目跟随。他们的具体情况和QARs可能与你的完全不同。

• 有效的架构评估需要基于实际的构建和测试来进行。推迟实施以寻求完美的设计方案通常会导致失败。

  
  

第二、决策的多元化：

• 避免让单一个体掌握所有决策权，而应促进团队内合适成员的共同决策参与。

• 架构设计实际上是在多个因素中寻找平衡点，通常涉及一系列并非完美的妥协方案。实现高性能、可扩展性、安全性、可维护性和优秀的用户体验是一项挑战。

• 当决策仅由一个人做出时，最终的架构可能只反映该人的经验、偏好和局限性。尽管有时这种方式可能刚好适合项目，但更多情况下可能会在某些方面表现出色，而在其他方面则欠佳。

• 来自不同背景的团队成员之间的健康讨论可以帮助揭示开发团队需要考虑的各种权衡。通常，团队中最高级别的人独自作出或影响决策（即所谓的“HiPPO”现象），往往难以获得团队全体成员的支持。成员们可能因担心工作安全而不公开反对，但如果这些决策导致问题，他们可能会迅速批评、停止支持团队，甚至离职。

• 这不是说决策应由多数人决定。委员会设计的架构往往过于复杂且缺乏焦点。经验表明，最佳的做法是让几位具有不同经验和观点的同事共同讨论和质疑，以便做出更明智的决策。

第三、合理的重用策略：

• 避免仅仅因为追求重用目的而作出不恰当的决策。应在适当时机考虑重用资源。

• 重用代码、组件、设计甚至配置在理论上是降低成本、加速交付、提升产品质量的有效手段。这一观点常受到管理层的推崇，有些团队甚至会倾向于重用现有应用程序的大部分内容来快速开发最小可行产品（MVP），或重用已成功实施的架构。

• 在功能较为单一的服务或类/类型中重用代码通常是有效且高效的，因为这些功能范围较小，副作用也相对有限，易于适应不同场景。然而，在架构层面，预期的重用效益通常不易实现。架构本身基于广泛且根本的假设，这些假设往往难以兼容不同的应用环境。

第四、不要轻易放弃那些有经验的人，他们在解决架构挑战方面很有价值。相反，应该保留并在必要时对他们进行再培训

管理层常常只关注于削减成本，有时这种做法是受到奖金激励的影响，鼓励经理通过减少特定比例的成本来获得奖励。他们可能会误以为软件开发技能是普遍可得的，因此被承诺说低成本的供应商可以提供与有多年甚至几十年经验的团队成员同等的技能所吸引。

有时候这是对的。正如我一位前同事所说，拥有十年经验和重复十次一年经验是完全不同的。换句话说，软件开发的真正技能并不仅仅是编码、掌握语法或熟悉某些框架，更重要的是解决问题的能力。

架构工作本质上是解决问题的过程，还需要能够根据以往解决类似问题的经验做出明智的权衡。那些没有在架构方面经验的开发者虽然能学习，但在学习过程中会犯很多错误。与之相比，雇佣或保留那些已经经历过这一学习过程的人，可能会更加经济实惠，这比仅仅依靠聪明才智而忽视经验更为重要。