软件的可维护性与可复用性(一)(Java与模式笔记)

第3章 软件的可维护性与可复用性

一个家用电器的维护，只是保持或者恢复电器的某种操作性能所需要的时间和资源。一个软件的维护则不同，它不仅包括清除错误和缺陷，而且还要包括对已有性能的扩充，以满足新的设计要求。

软件的维护就是软件的再生。一个好的软件设计，必须能够允许新的设计要求以较为容易和平稳的方式加入到已有的系统中去，从而使这个系统能够不断地焕发青春。一个可维护性好的系统，应当允许维护工作能够以容易，准确，安全和经济的形式进行。

导致一个软件设计的可维护性较低，也就是说会随着性能要求的变化而腐烂的真正原因有四个：过于僵硬（Rigidity），过于脆弱（Fragility），复用率低（Immobility），黏度过高（Viscosity）。
过于僵硬——很难在一个软件系统里加入一个新的性能。加入一个新性能，不仅仅意味着建造一个独立的新模块，而且因为这个新性能会波及很大其它模块，最后变成跨越几个模块的改动。只需要几天的工作最后可能需要花费两个月。
过于脆弱——对一个地方的修改，往往会导致看起来没有关系的另一个地方发生故障。
复用率低——这里的复用是指一个软件的组成部分，可以在同一个项目的不同地方甚至在另一个项目中重复使用。每当程序猿发现一段代码、函数、模块所做的事情是可以在新的模块、或者新系统中使用的时候，他们总是发现，这些已有的代码依赖于一大堆其它的东西，以至于很难将他们分开。
黏度过高——有的时候，一个改动可以以保存原始设计意图和原始设计框架的方式进行，也可以以破坏原始意图和框架的方式进行。第一种办法无疑会对系统的未来有利，第二中办法是权益之计，可以解决短期的问题，但是会牺牲中长期的利益。如果第二种办法比第一种办法要容易很多，程序猿就有可能牺牲中长期的利益，采取权宜之计：在模块中搭建一个短路桥，或者在一个通用的逻辑中制造一个特例，以便解决眼前的需要。
一个系统设计，如果总使得使用第二种办法比第一种办法容易，就叫做黏度过高。一个黏度过高的系统会诱使维护它的程序猿采用错误的维护方案，并惩罚采取正确维护方案的程序猿。

一个好的系统设计应该有如下的性质：可扩展性（Extensibility），灵活性（Flexibility），可插入性（Pluggability）。这三条性质就是一个系统设计应当达到的目标。