软件架构并不是预先进行大型设计

软件架构传统上与前期的大型设计和瀑布式交付联系在一起，在这种模式下，团队会确保在编写任何代码之前，软件设计的每一个元素都得到充分考虑。2001 年的《敏捷软件开发宣言》提出，我们应该重视“响应变化而非遵循计划”。不幸的是，许多团队从字面上理解这一点，误解为不应该进行规划。最终的结果是，一些软件开发团队已经从前期进行大型设计转变为不进行前期设计，这一点我在世界各地的许多组织中都亲眼目睹过。

预先进行大型设计很愚蠢。不预先进行任何设计则更愚蠢。
戴夫·托马斯

两种极端都是愚蠢的，如果你愿意接受这一点，即前期设计并不一定意味着要创造一个完美的最终状态，那么就很容易找到一个最佳平衡点。相反，前期设计应该被视为一个起点，并为团队设定一个方向。这个经常被忽略的步骤可以为团队带来巨大的价值，鼓励他们了解自己将要构建什么以及它是否有效。

重大决定

为了完成软件设计，您需要做出一些设计决策。在讨论架构和设计之间的区别时，Grady Booch 告诉我们：“架构代表着重要的决策，其重要性是通过变更成本来衡量的。”换句话说，哪些决策在日后更改会付出高昂的成本？

思考前期设计的一个好方法是确保你已经做出并理解与“重大决策”相关的权衡。这些重大决策通常与技术选择（例如编程语言、框架、协议、产品等）和结构（例如分解策略、模块化、功能边界等）有关。

如果您正在构建一个单体软件系统，那么编程语言的选择可能会因多种原因而变得至关重要。采用微服务架构可能会降低编程语言选择的重要性，但也会带来其他需要考虑的权衡，包括一些本质上与社会技术相关的权衡。同样，采用六边形架构可以让您将业务逻辑与技术选择分离，但同样也存在一些权衡。

因此，前期设计过程应该着眼于理解那些影响软件系统形态的重要决策，而不是仅仅理解数据库表中每列的长度。实际上，我希望团队能够理解他们要构建什么，如何构建（从高层次上讲），以及他们所设计的东西是否真的有潜力发挥作用。

前期设计需要多少？

但是，团队应该做多少前期设计呢？这是我被问到最多的问题之一，敏捷团队常常困惑于他们应该做多少前期设计，或者他们是否应该做前期设计！我推荐的方法可以概括如下：

• 在开始编码之前进行“一些”前期设计。
• 随着您的进步、学习和交付功能，持续进行进化设计。

“一些”指的是相当模糊的前期设计量，它属于那种“视情况而定”的情况，具体情况很重要。有些团队可以只做很少的前期设计，而有些团队则需要做更多。或许更好的方法是将前期设计也视为一个迭代和增量的过程，并思考“我们什么时候应该停止前期设计？”。我的观点是，在以下情况下应该停止前期设计：

• 您了解重要的架构驱动因素（要求、质量属性、约束）。
• 您了解所构建内容的背景和范围。
• 您了解重要的设计决策（即技术、模块化等）。
• 您有办法向其他人传达您的技术愿景。
• 您确信您的设计满足关键的架构驱动因素。
• 您已经识别并接受与构建软件相关的风险。

就具体方法而言，我倾向于对团队采取以下做法：

• 举办分析研讨会，从高层次了解需要构建的内容范围。如果我能自信地绘制系统环境图，我们就能了解谁在使用我们正在设计的软件系统，以及它如何融入周围的生态系统。
• 举办设计研讨会，目标是创建容器图。这样做可以让我们了解软件系统的构建方式，以及我们正在做出的与技术和模块化相关的重要决策。请记住，这只是一个起点，随着我们收到反馈，设计可能会（并且将会）发生变化。
• 进行风险识别练习（例如风险风暴），以便我们了解该方法是否可行，以及最高优先级的风险所在。有了这些信息，我们可以根据需要调整设计，或者编写代码（例如原型、概念验证、行走骨架等）来降低实施风险。

从时间尺度来看，这是“小时/天/周”，而不是“周/月/年”。这个话题太大，无法用一篇博文来概括，所以让我给你推荐一个去年 YOW! 大会上名为“失落的软件设计艺术”的演讲视频。

概括

软件架构并非事前进行大规模设计。在开始编码之前，先进行一些前期设计，作为起点，并准备好随着开发、学习和功能交付不断改进设计。