Question

软件的一个主要分歧是要做多少预先设计。对于应该什么时候做设计和应该做多少，人们是非常两极化的。以我和软件团队工作的经验，基本上有以下几类观点：

“在开始编码之前，我们需要预先做好所有的软件架构”；

“软件架构不需要预先完成，我们会逐步演化它”；

“嗯，我们拥有一支优秀的团队，不需要做软件架构”。

这些不同的观点引出了一个有趣的问题，你需要预先做多少架构？

回到方法学

分歧的一个主要原因来自于团队如何工作，具体到他们遵循的是哪种开发方法学。如果从提倡多少预先设计来对常见的软件开发方法进行比较，你会得到如下的图。

一头是瀑布式，它的典型形式是大型预先设计，推崇在开始编写代码之前，每件事都必须决定、评审和签发。另一头则是表面看来回避架构的敏捷方法。

可以说这一点不是真的。敏捷方法没有说“不做架构”，就像它们没有说“不产出任何文档”。敏捷是充分度、快速行动、拥抱变化、反馈和交付价值。但因为敏捷方法和它们的布道者不强调软件开发的架构层面，很多人都将其误解为“敏捷说不做任何架构”。更常见的是，敏捷团队选择把设计工作分散到整个项目，而不是全部预先做。对此有几种说法，包括“演化架构”和“浮现式设计”。根据软件系统的规模和复杂度以及团队的经验和成熟度，最终这可能不幸地演变成“盲目乐观”。

两头中间的是像Rational统一过程（RUP）1、规范敏捷交付（DAD）2和动态系统开发方法（DSDM）Atern3这样的方法。这些是灵活的过程框架，实现中可以全部或部分采用。尽管RUP实现往往是与瀑布式方法有更多共同点的重量级怪物，它也可以缩减规模，呈现出能让它占据中心地带的特征组合。DAD基本上是一个精简版的RUP，而DSDM Atern则是一个类似的迭代和增量方法，也受到敏捷运动的影响。三者都是风险驱动的方法学，基本上就是“集中主要的高层次关键需求，规避风险，然后迭代和增量”。DSDM Atern甚至使用术语“坚实的基础”来形容这一点。做对了，这些方法就能在预先设计和演化架构之间达到良好的平衡。

1http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process

2http://en.wikipedia.org/wiki/Disciplined_Agile_Delivery

3http://en.wikipedia.org/wiki/Dynamic_systems_development_method

要做到“恰如其分”

对于预先架构和设计，我的方法是要做到“恰如其分”。如果你对人们这样说，他们要么认为这是鼓舞人心的新鲜空气，完全符合他们已有的信念，要么认为这是彻头彻尾的逃避责任！“恰如其分”是一条准则，但它是模糊的，对人们评估多少算够没有太大帮助。根据我对架构的定义，你可以说自己需要做恰如其分的预先设计来得到结构和愿景。换句话说，做到足够才会知道自己的目标是什么，要如何实现它。这是一条更好的准则，但仍然没有提供任何具体的建议。

事实证明“恰如其分”的预先设计很难量化，因此很多人根据自己过去的经验，对“太少”或“太多”都有坚定的主张。这里总结的思想来自我过去几年遇到的软件开发者

多少预先设计是太少

不了解系统边界是什么，在哪里。

团队中对“大局”没有形成共识。

无法交流整体愿景。

团队成员对需要做的事情不清楚或感到不适。

没有考虑非功能需求/质量属性。

没有考虑（现实的）环境约束如何影响软件（比如部署环境）。

没有考虑主要的风险，比如非功能需求、外部接口等。

尚未确认重大问题及其答案。

没有考虑关注点分离、适当的抽象层次、分层、可修改性，拐点等。

对架构师要扮演的角色没有共识。

解决问题的方法不一致。

团队缺乏控制和指导。

项目生命周期中本应预先考虑到的重大架构变化。

过多的设计选择和选项，往往伴以团队成员对解决方案或前进方向的反对。

对于设计是否管用的不确定（比如，设计过程中没有执行原型的部分）。

缺乏技术选择（即不必要的延迟）。

多少预先设计是太多

太多信息（即很长的文档或信息超载）。

在太多抽象层次都过于详细。

太多图表。

在文档中编写代码或伪代码。

过于死板，缺乏灵活性的架构。

所有抽象层次的所有决策都已做出。

有着众多展示了所有可能交互的序列图的类层次设计。

详细的实体关系模型和数据库的设计（比如，表、视图、存储过程和索引）。

分析瘫痪和纠缠于次要细节的团队。

编码成了对团队来说无聊而消极的设计文物到代码的简单变换。

一个无节制的“设计阶段”（即时间和预算）。

还未进行任何编码就已到达最后期限。

多少是“恰如其分”

上面很多答案都不难得到认同，但是“恰如其分”仍处于两个极端之间的灰色地带。关键是架构代表了重大的决策，而衡量重要性的则是改变的成本。换句话说，就是修改起来真的很昂贵，也真的需要尽早做对的东西。举个例子，高性能、高可伸缩性、高安全性和高可用性等质量一般需要尽早融入基础中，因为它们很难安插到已有的代码库中。重大的决策也包括那些你不能用一个下午就轻松完成重构的东西，比如整体结构、核心技术的选择、“架构”模式、核心框架等。

暂时回到RUP，它使用了“架构上重要”这个术语，建议你应该找出什么可能对你的架构重要。什么可能是重要的？嗯，任何改变成本高、复杂（比如棘手的非功能需求或约束）或新的东西。在现实中，如果你没把这些事做对，它们就会有高于正常风险的后果。重要的元素往往也是主观的，会根据团队的经验有所变化，这一点值得铭记。

在这里你有的就是一种软件开发方法，它使你可以为了构建向前发展的充分基础而关注什么是有风险的。无论什么方法学，识别架构上重要的元素及其相应的风险，都应该应用到所有的软件项目。如果你需要引入一个架构冲刺，某些敏捷布道者会说“你错了”，然而一些敏捷项目已经引入了一个“冲刺零”来做这件事。我说，你需要做任何基于你自己的语境、对你管用的。

尽管所有这些提供了一些指导，然而“多少才是恰如其分”这个问题的答案却要“看情况”，因为每个软件团队都不一样。有些团队更有经验，有些需要更多指导；有些一直在一起工作，有些频繁地轮换和变动；有些软件系统有大量必要的复杂性，等等。那么你需要做多少架构？我说，你需要做到“恰如其分”，以便做到以下几点，不管软件架构角色是由一个人扮演还是团队内共享这些都适用。

01. 结构

02. 是什么：理解主要的结构元素，以及它们如何基于架构驱动力组合在一起。

03. 怎么做：设计并分解为容器和组件。

风险

是什么：识别和缓解最高优先级的风险。

怎么做：风险风暴和具体的实验4。

4http://www.agilemodeling.com/essays/agileArchitecture.htm#ProveIt

愿景

是什么：创建并交流团队展开工作的愿景。

怎么做：语境、容器和组件图。

这个软件架构实践的最小集合将为你提供支撑软件交付的其余部分的坚实基础。有些架构通常确实需要预先完成；但是有些则不是，还能够自然地演化。关键在于找准强制性和演化设计的分界线。

把恰如其分的预先设计置于适当的语境

在现实中，你必须回答“多少预先设计是足够的“，我建议实践架构一个软件系统。找到或创建一个中小型软件项目的场景，制定一个很短的高层次需求（功能和非功能）集合来描述。这可以是一个你已经参与工作过的已有系统，或者是跟你的领域不相关的新东西，比如我在自己的培训课程上用的金融风险系统。有了这个，再要求两组（每组2~3人）或更多的人通过选择一些技术，做一些设计，绘制一些用于交流愿景的图，找出一个解决方案。为这个活动规划好时间（比如90分钟），然后主持一个开放的评审会议，对每个解决方案提出以下类型的问题。

架构会管用吗？如果不管用，为什么？

所有关键的风险都已被识别了吗？

架构是否过于简单？是否过于复杂？

架构是否有效地交流过？

图的哪些地方是受人喜欢的？哪些可以改进？

细节是否太多？细节是否足够？

你能把这作为起点交给你的团队吗？

控制是否太多？指导是否不足？

你对已做出或推迟的技术决策的程度满意吗？

把这个练习看作一种架构演练5，不过你要进行一次评审，主要集中在你所经历的过程以及产出，而不仅仅是架构本身。记录你的发现，尝试为将来处理软件设计流程提炼出一套指导。商定要深入多少细节并包含示例，商定图表表示法并包含好的图表示例，确定你自己的环境中的通用约束，等等。如果可能的话，记住这些指导，反复练习，看看它如何带来改变。通常一天足够进行几次包含设计/沟通/评审周期的练习。

5http://blogs.tedneward.com/2010/06/17/Architectural+Katas.aspx

没有一模一样的软件团队。留出一天，在你自己的环境中实践软件的设计流程，这会为你将来应对这一流程提供一个一致的起点，帮助你在适当的语境中搞清楚究竟什么样的预先设计对你和你的团队而言“恰如其分”。实践软件设计流程还有一个额外的好处，它是培训和指导其他人的好方法。你在追求一个人人都能扮演软件架构角色的自组织团队吗？