粘滞性-teamtrac.pptVIP

软件的降级和腐化 S李冰川 软件设计腐化的症状： 僵化性（Rigidity） 脆弱性（Fragility） 牢固性（Immobility） 粘滞性（Viscosity） 不必要的复杂性 晦涩性（Opacity） 僵化性： 僵化是指难以对软件进行改动，即使是简单的改动。如果单一的改动会导致有依赖关系的模块中的连锁改动，那么设计就是僵化的。必须要改动的模块越多，设计就越僵化。 　　大部分开发人员都遇到这样的情况：他们对被要求进行一个看似简单的改动，当他实际进行改动时，才发现有许多改动带来的影响自己并没有预测到。最后，改动所花费的时间要远比初始估算长。 脆弱性 脆弱性是指，在进行一个改动时，程序的许多地方就可能出现问题。常常是，出现新问题的地方与改动的地方并没有概念上的关联。要修正这些问题就又会引出新的问题，从而使软件开发团队就像一只不停追逐自己尾巴的狗一样。 牢固性 牢固性是指，设计中包含了对其他系统有用的部分，但是要把这些部分从系统中分离出来需要的努力和风险是巨大的。这是一件令人遗憾的事，但却是非常常见。 粘滞性 当面临一个改动时，开发人员常常会发现会有多种改动的方法。其中，一些会保持设计；而另外一些会破坏设计（也就是生硬的手法）。当那些可以保持系统设计 的方法比那些生硬手法更难应用时，就表明设计具有高的粘滞性。做错误的事情是容易的，但是做正确的事情却很难。这样就很难保持项目中的软件设计。 不必要的复杂性 如果设计中包含当前没有用的组成部分，它就含有不必要的复杂性。当开发人员预测需求的变化，并在软件中放置了处理潜在变化的代码时，常常会出现这种情况。起初，这样看起来是一件好事。毕竟，为将来的变化做准备会保持代码的灵活性，而且可以避免以后再进行痛苦的改动。 糟糕的是，结果常常正好相反。为过多的可能性作准备，致使设计中含有绝不会用到的结构，从而变得混乱。一些准备也许会带来回报，但是更多的不会。期间，设计背负着这些不会用到的部分，使软件变得复杂，而且难以理解。 不必要的重复 复制（Copy）和粘贴（paste）也许是有用的文本编辑（text-editing）操作，但是它们却是灾难性的代码编辑（code-editing）操作。 当系统中有重复代码时，对系统进行改动会变得困难。在一个重复的代码体中发现的错误必须要在每个重复体中一一修正。不过，由于每个重复体之间都有细微的差别，所以修正的方式也不总是相同的。 晦涩性 晦涩性是指，代码模块难以理解。当开发人员最初编写一个模块时，代码对于他们来说看起来也许是清晰的。这是由于他们使自己专注于代码的编写，并且他们对 于代码非常熟识。在熟识减退以后，他们或许会回过头来再去看那个模块，并想知道他们为什么会编写出如此糟糕的代码。为了防止这种情况发生，开发人员必须要 站在代码阅读者的位置，共同努力对他们的代码进行重构。 1 什么激发了软件的腐化 什么激发了软件的腐化？答案是需求的变化。由于需求没有按照初始设计预见的方式进行变化，从而导致了设计的退化。通常，改动都很急迫，并且进行改动的开发人员对原始的设计思路并不熟识。因而，虽然对设计的改动可以工作，但是它却以某种方式违反了原始的设计。随着改动的不断进行，这些违反不断地积累，设计开始出现臭味。 然而，我们不能因为设计的退化而责怪需求的变化。作为开发人员，我们对需求变化有非常好的了解。事实上，我们中的大多数人都认识到需求是项目中最不稳定的因 素。如果我们的设计由于持续、大量的需求变化而失败，那就表明我们的设计和实践本身是有缺陷的。我们必须要设法找到一种方法，使得设计对于变化具有弹性， 并且应用一些实践来防止设计腐化。 然而，我们不能因为设计的退化而责怪需求的变化。作为开发人员，我们对需求变化有非常好的了解。事实上，我们中的大多数人都认识到需求是项目中最不稳定的因 素。如果我们的设计由于持续、大量的需求变化而失败，那就表明我们的设计和实践本身是有缺陷的。我们必须要设法找到一种方法，使得设计对于变化具有弹性， 并且应用一些实践来防止设计腐化。 2 设计腐化的例子 从键盘读入字符，并输出到打印机。 void Copy(){int c;While ((c = RdKbd()) !=EOF)WrtPrt(c);} 老板又来找你，说有时希望能从纸带读入机读入信息。 bool ptFlag = false;void void Copy(){int c;While ((c = (ptFlag ? Rdpt() : RdKbd())) !=EOF)WrtPrt(c);} 想让Copy程序从纸带读入机读入信息的调用者必须把ptFlag设置为true，然后再调用Copy时，它就能正确地从纸带读入机