软件架构：控制与改进

         在漫长的生命周期中，有些软件越做越好，有些软件越做越差。现在我们要关注的是：如何在一个较长的时期内，把一个软件越做越好。这就是软件开发的控制与改进。         影响软件质量的因素有很多，但本文主要考虑的是控制。为了达到这个目的，我们首先来设定一个理想的环境。在这个环境下，我们假设：意外不会发生。我是说灾难性事件不会发生，没有任何意料之外、完全不可控的事情。
团队有一定的资格，相对稳定。
在这个前提下，我们考察相对较长时间内，软件质量控制及稳定提升的关键行动。这个话题涵义很广，我们只讨论其中的关键点：把握好了可以达到事半功倍的效果。 需求控制需求控制的手段主要是评审和变更控制。需求控制的标准主要有两个：价值符合度标准和目的符合度标准。价值符合度标准用来衡量需求的目的是否符合客户和用户的价值，是否可以直接或间接给用户带来益处。目的符合度标准用来判定需求的细节是否符合需求的最终目的。通过这两个标准可以判断一个需求的稳定程度，它变化的可能性有多大。需求的稳定程度要记录下来，做为设计阶段的参考。 设计控制最有效的设计控制手段是封装。封装一般性的东西以重用；封装稳定程度差的需求以适应将来的变化；封装不太确定的设计决策以便将来可以采用更好的方法。良好的封装是软件质量持续改进的基础。现实世界本来就存在依赖关系，封装在某种程度上可能会导致非自然的依赖关系。对依赖关系的控制从反面影响软件的质量，要注意保持依赖关系是单向的，包之间绝不应该存在双向的甚至是循环的依赖关系。依赖关系严重影响软件的可修改性。 编码控制编码控制的核心是避免错误。最大的错误就是违反设计，破坏封装和引入设计定义之外的依赖关系。要对每一个编码的单元进行这些方面的检查，避免“千里之堤，溃于蚁穴”。实施控制的时机一般来说，阶段性评审是最好的时机；变更控制过程是必须的时机；如果上述两种时机你没有把握住的话，周期性评估是最后的时机。 实施改进改进是软件越做越好的手段。控制不能让你的软件变好，只能让你的软件不会变得更坏。但是无论如何，控制是改进的基础，没有控制的话你就别想改进。改进的手段包括重构和重做。需求变化时，极可能带来设计的变化。这需要对需求变更和原来的设计进行评估，这是重构的好时机。这就是重构的原则，不要在错误的基础上继续工作。打补丁一样的开发只会让软件越来越糟糕。有时候重做整个或部分软件也是必须的。原则上重做也是越早越好，付出的代价也越小。如果你的车油量降到了一半以下，你就永远也不可能回到起点了。