质量.软件.管理--系统思维(15)

第15章 错误排除动力

- 基本的错误排除动力，实际上就是规模/复杂度动力的另一种表现形式。随着软件系统规模的不断扩大，将会出现更多的错误，同时每个错误（在排除过程中）的复杂度也将提高--这样，就会使在错误排除方面需要的时间总量以非线性的速度增加。

- 由于副作用的存在，给错误排除增加了更多的非线性。你在不经意之间所做的某个改动，很可能会引发其他地方的改动--如果你不舍得花时间对这类副作用进行分析研究，那么你必将招致这些副作用，并最终自食其果。

- 最显而易见的一类副作用发生在错误反馈方面，这种作用的强度可以通过错误反馈率这一指标进行度量。所谓的错误反馈，实际上就是指在修正原有错误的同时，又引发了（更多）新的错误。这里所说的错误即可以是功能性的，也可能是系统性能方面的。

- FFR是可以指示项目控制水平衰退的一个敏感指标。如果对一个项目的控制良好，那么随着项目最终期限的临近，FFR应该逐渐降低，直到最后降为零。

- 为了将FFR置于我们的控制之下，一种办法就是建立一套严格的规定--对每一错误排除的结果（哪怕只修改了一行代码），都要进行仔细的复查。如果我们天真地认为小范围的改动不至于引起大问题，那么实际上，这些小改动往往将会比更大的改动引发出更多的问题。

- 除了错误以及性能不足等方面之外，软件系统的退化还会表现在其他一些方面；而且，通过常规的测量指标，并不能反映出这些问题。这类问题的例子有：设计的整体性受到破坏、文档未能更新以及代码风格不一致等。所有这些问题，都会进一步降低系统的可维护性。

- 如果模块（或者成为黑盒）的整体性受到破坏，那么在对系统进行后续调整的时候，连锁效应将会越来越强烈。也就是说在这种情况下，对系统的每一次更改，都会引起很多地方的更改。

- 为了避免系统的质量退化，他们不仅要对系统本身进行维护，同时还要对其可维护性进行维护。

- 无论是管理人员还是开发人员，都会自认为不会在系统维护方面遇到多少麻烦。因此在最初的设计阶段，他们都会显得信心十足。在这种有目的的自信支配下，人们会天真地认为自己的代码绝对不会出现问题面前--正是由于这种观念的作用，他们往往会重蹈泰坦尼克号的覆辙。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/6906/viewspace-610672/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/6906/viewspace-610672/