软件架构复杂性讨论总结

在2024年11月12日的iSAQB软件架构大会（Software Architecture Gathering）上，一场关于软件复杂性的专题讨论引发了多位专家的见解，并提出了几条以他们名字命名的“定律”。这些定律为软件架构师和工程师提供了宝贵的建议。

专家观点与定律

1. Gregor Hohpe的定律
   Gregor Hohpe（《The Architect Elevator》作者）提出：“过度复杂性是组织无法做出决策时，自然给予的惩罚。”

   • 他认为，复杂性是组织决策能力不足的结果。

2. Chris Richardson的定律
   Chris Richardson（《Microservices Patterns》作者）提出：“一个架构元素只有在解决实际问题时才有存在的必要。”

   • 他警告避免引入“偶然复杂性”，即为了解决原始复杂性而构建的系统本身带来的复杂性。

3. Diana Montalion的定律
   Diana Montalion（《Learning Systems Thinking》作者）修订了Mel Conway的观点，提出：“设计系统的人会复制他们的思维和沟通模式。”

   • 她强调，复杂性不等同于复杂性，软件系统的目标不应是消除复杂性，而是减少不必要的复杂性。

复杂性与系统设计

• 复杂性的管理

  • Lars Roewekamp（Open Knowledge GmbH创始人兼首席信息官）指出，只有在能够衡量额外成本时，才应引入额外的复杂性。
  • 专家们一致认为，复杂性随时间变化，系统设计时应考虑波动性。

• 波动性与架构设计

  • Richardson在大会上曾演讲“快速流动的架构模式”，强调架构师需要识别系统中波动性最大的部分，并特别设计这些区域，以实现松耦合。
  • Montalion认为，确定性是一种幻觉，软件架构师的价值在于在不确定的环境中产生影响。

架构的价值与人类因素

• 架构价值的衡量

  • Rebecca Parsons（Thoughtworks前首席技术官）指出，架构的价值很难提前衡量，但应尽早决定如何衡量，并通过紧密的反馈循环进行调整。

• 人类因素与复杂性

  • Hohpe指出，复杂性增加往往与人们对变化的恐惧有关。例如，如果人们从过去的项目中学到，后期变更成本高昂或不可能实现，他们可能会在初期提出过多的需求。
  • 架构师可以通过使这些问题可见，帮助识别瓶颈并改进流程。
  • 他还提到，复杂性不是预算中的一项，人们通常认为它成本为零，但架构师需要将复杂性转化为业务能够理解的语言，以减少复杂性。

会议背景

• 本次会议由Rainald Menge-Sonnentag和Alexander Heusingfeld主持，国际软件架构资格委员会（iSAQB®）在德国柏林举办，时间为2024年11月11日至14日。下一届会议将于2025年11月24日至27日在柏林举行。

总结

本次讨论围绕软件复杂性的管理展开，专家们通过各自的“定律”和见解，强调了在架构设计中如何有效处理复杂性和波动性，并探讨了人类因素对复杂性的影响。会议为软件架构师提供了实用的指导，帮助他们在不确定的环境中设计出更具适应性的系统。