设计的现在进行时

    建立敏捷架构并不只是为了更好地预测结果，许多措施不但可以简化正在进行中的工作，并且同样有长期效益。只有那些完备的代码才有清晰的表达能力；并且只有那些技术负债较少的代码才会使架构成为轻松愉快的工作环境。因此，与架构相关的过程是实现架构敏捷性必不可少的一部分。

    一直以来，大家都希望能在早期阶段完成所有的架构工作，通过大规模预先设计减少以后可能遇到的风险。想法是很好，可惜这种方式是在项目周期中对项目了解最少（或最无知）的情况下来做出最重要的决策，结果不但没有减少风险，反而使风险更多，同时还损失了对变化的响应能力——因为你已经做好计划，就得按计划做下去。

    风险应该是在开发过程中逐渐消除的。一个有反馈机制的过程有足够的机会检测不确定性、减少投机因素、标明正在出现的问题，以及纠正方向。敏捷过程中已经有了这些机制，它们对架构同样有用，就像在项目其它方面的作用一样。这里有许多技巧：

* 根据架构历史，预测系统趋势和质量，包括好的方面与不好的方面。如果有经常发生缺陷的部位，或者经常需要替换的代码的详细资料，就会使这方面的工作更简单一些。
 
* 在开发过程中明确地说明技术负债，比如把有问题的部分以有规律、易于查找的方式标记在代码中，或张贴在信息公告板上。确保这些技术问题都有一个入口，并且已经着手解决，而不仅仅是标记出来。
 
* 如果有数据表明架构有问题，比如依赖性管理不善，那就把改变这些数据作为目标。这些数据甚至可以作为构建验证指标的一部分，但要注意，不能过于依赖这些数据，因为它们只在有问题并且可以作为解决问题的参考时才有价值。一旦它们吸引了过多的精力或者已经完成它们的使命，就可以扔掉它们继续前进。

* 可以用不确定性来区分代码。如果需要在两个选项之间做一个选择，那么更应该注意，问题不是“我要选择哪一个？”而是“怎么设计才能让选择变得不重要？”将不确定性封装起来可以减少选择带来的影响，避免由于信息和情况的变化而需重新选择的窘境。

* 考虑到日程安排，不确定性也可以有创造性的应用。由于不确定性通常是由于信息不足造成的，因此不要武断地做出决策。可以将决策往后顺延，直到有足够的信息可以做出可靠的决策，当然也要避免过度拖延错过最后的可靠时机（Last Responsible Moment）以至不可收拾。

    这些技巧（包括其它技巧）可以使团队体验、采用并最终取得一个可靠的过程。架构是一个实验过程：从一个清晰的蓝图开始，然后根据新信息随时做出响应。不成熟的做法经常会忽视架构，认为一个优秀的架构会随时间发展自然生成，或者认为有了优秀的工具和积极的团队便无需架构。

    跟其它形式一样，这是一个脚踏实地的过程。如果没有这方面的认识、指引和培养，一个全副武装、积极进取的团队可能也会发现，虽然越来越善于做一些修补工作，但最终困在技术负债里，找不到无休无止修补循环的根本原因。这种缺乏可预测性的架构缺少的是概念上的完整性，正如Mary和Tom Poppendieck在《精准软件开发》一书中所说：

    概念完整性就是指系统的核心概念能够平滑、紧凑地结合为一个整体。各组件能够互相匹配、紧密合作，那么架构便能找到灵活性、可维护性、效率和响应性的完美平衡点。

    优秀的架构其价值也许并不会直接体现在商业价值上，但它可以减少实现商业价值所需的成本，而具体体现在可以减少开发过程中常见浪费资源上。