在漫长的生命周期中，有些软件越做越好，有些软件越做越差。现在我们要关注的是：如何在一个较长的时期内，把一个软件越做越好。这就是软件开发的控制与改进。

影响软件质量的因素有很多，但本文主要考虑的是控制。为了达到这个目的，我们首先来设定一个理想的环境。在这个环境下，我们假设：

• 意外不会发生。我是说灾难性事件不会发生，没有任何意料之外、完全不可控的事情。
• 团队有一定的资格，相对稳定。

在这个前提下，我们考察相对较长时间内，软件质量控制及稳定提升的关键行动。这个话题涵义很广，我们只讨论其中的关键点：把握好了可以达到事半功倍的效果。

需求控制

需求控制的手段主要是评审和变更控制。需求控制的标准主要有两个：价值符合度标准和目的符合度标准。价值符合度标准用来衡量需求的目的是否符合客户和用户的价值，是否可以直接或间接给用户带来益处。目的符合度标准用来判定需求的细节是否符合需求的最终目的。通过这两个标准可以判断一个需求的稳定程度，它变化的可能性有多大。需求的稳定程度要记录下来，做为设计阶段的参考。

设计控制

最有效的设计控制手段是封装。封装一般性的东西以重用；封装稳定程度差的需求以适应将来的变化；封装不太确定的设计决策以便将来可以采用更好的方法。良好的封装是软件质量持续改进的基础。现实世界本来就存在依赖关系，封装在某种程度上可能会导致非自然的依赖关系。对依赖关系的控制从反面影响软件的质量，要注意保持依赖关系是单向的，包之间绝不应该存在双向的甚至是循环的依赖关系。依赖关系严重影响软件的可修改性。

编码控制

编码控制的核心是避免错误。最大的错误就是违反设计，破坏封装和引入设计定义之外的依赖关系。要对每一个编码的单元进行这些方面的检查，避免“千里之堤，溃于蚁穴”。

实施控制的时机

一般来说，阶段性评审是最好的时机；变更控制过程是必须的时机；如果上述两种时机你没有把握住的话，周期性评估是最后的时机。

实施改进

改进是软件越做越好的手段。控制不能让你的软件变好，只能让你的软件不会变得更坏。但是无论如何，控制是改进的基础，没有控制的话你就别想改进。改进的手段包括重构和重做。

需求变化时，极可能带来设计的变化。这需要对需求变更和原来的设计进行评估，这是重构的好时机。这就是重构的原则，不要在错误的基础上继续工作。打补丁一样的开发只会让软件越来越糟糕。

有时候重做整个或部分软件也是必须的。原则上重做也是越早越好，付出的代价也越小。如果你的车油量降到了一半以下，你就永远也不可能回到起点了。

软件架构, 控制, 改进, control, improvement, architecture