软件的可维护性和可复用性

 一、软件系统的可维护性

　　统计证明，软件维护的成本是原始开发的很多倍。

1.软件的维护

　　软件的维护与家用电器不同，后者的维护成本只是保护或恢复某种功能所需的时间和资源，因此家用电器的维护成本远低于购买或开发成本。而软件的维护不仅包括清 除错误和缺陷，而且还要对已有性能进行扩充，满足新的设计要求。换言之，维护中的软件是一个不断再生的软件，像一个“不断带来新礼物的礼物”。拿电视来类 比，就好比你先购买了一个黑白小电视，随着要求的提高，将它改造为一个彩色大电视一样。

　　软件的维护就是软件的再生。好的设计，必须能允许新的设计要求以较为容易和平稳的方式加入已有的系统中去。可维护性好的系统，维护工作能够以容易、准确、安全和经济的方式进行。

一个典型的软件生命周期

　　设计师们根据最初的设计要求设计出了原型系统，然后由程序员实现为一个优美的产品。这时的系统优美纯洁。然后客户接踵而来的小小修改要求彻底毁了它。人们不 得不采取权宜之计来平衡新的要求与旧系统之间的矛盾。随着修改部分在系统中的权重逐渐增加，这个系统最终变成了一堆散发着臭味的垃圾。人们碰也不愿意碰 它。直到最后人们终于忍无可忍，带着解脱的心情将它抛弃，重新开发。然后，历史将会重演….

设计师的辩解

设计师们说，系统腐烂的原因是由于：

　　1.用户变化无常，使得设计无法跟上快速的变化，原有的设计没有给未来的变化预留空间。

　　2.维护设计师和原始设计师往往不是一个人，因此对原有系统的理解是否正确也是一个问题，即使原有的设计可以容纳变化，维护设计师也常常没有发现这一点。

　　3.所有，新的改动总是以破坏原有意图和框架的方式加入进去。而且它是日积月累造成的，因此维护设计师不能形成自己的风格和设计框架。就像一堆补丁东拼西凑在一起。直到原有的系统设计毁坏殆尽，彻底腐烂。

　　我们要思考的是，软件系统的性能要求一定会变。我们能不能在最初的设计中为日后的变化留出空间呢？

真正的原因

Rober C Martin指出，导致一个软件可维护性低的原因有四：过于僵硬（Rigidity）、过于脆弱(Fragility)、复用率低（Immobility）、黏度过高(Viscosity).

（1）过于僵硬

　　一个系统做好之后，任何一个新功能的加入，都会影响许多模块，最终演变成几个模块的大改动。因此，一个系统一旦做好后，不敢加入任何新的功能。这就是系统的僵硬化。（LY注：从加入新功能的角度看待系统。我认为造成这种现象的原因是系统的各个模块分隔的不好，或者它们之间的联系过于紧密。）

（2）过于脆弱

　　与僵硬化同时存在的，是软件修改已有代码时非常脆弱。对一处的修改，往往造成不相干的地方发生故障。这种一碰就碎的情况，叫做系统的脆弱性。

（3）复用率低

　　复用，就是指一个软件的组成部分，可以在同一个项目的不同地方甚至另一个项目中重复使用。程序员发现一部分代码、函数和模块所做的事情可以在新的模块、系统 中使用。但是他们发现这些东西依赖的东西太多，很难将其剥离开来。因此最好的方法是重新写。这种系统有复用率低的特点。

（4）黏度过高

　　一 个改动可以以保留原始设计意图和原始设计框架方式进行，也可以以破坏原始意图和框架的方式进行。第一种对系统的未来有利，第二种是权宜之计，可以解决短期 问题，但是会牺牲中长期的利益。如果一个系统的设计使得维护总是采用第二种方式比第一种容易，那么就叫做黏度过高。这会诱使程序员采取不正确的维护方案。

设计的目标

好的系统应具有如下的性质：可扩展性(Extensibility)、灵活性（Flexibility）、可插入性(Pluggability)

（1）可扩展性

新的功能应该很容易的加入到系统中而不影响到系统原有的其他方面。这就是可扩展性，与过于僵硬相对应。

（2）灵活性

允许代码灵活修改，不会影响到其他的模块。这就是灵活性，与过于脆弱是相对应的。

（3）可插入性

容易将一个类抽出去，将另一个有相同借口的类加进来。这就是可插入性。是黏度过高的反面。

为了满足这三项设计要求，关键是适当的提高软件的可维护性和可复用性。

2.系统的可复用性（Reuse）

复用又叫重用，是重复使用的意思。目前，一般软件的复用率并不高，尤其在国内。

复用的好处：

　　1.较高的生产效率。（以及随之而来的成本降低）

　　2.较高的软件质量。（错误可以更快的被纠正）

　　3.恰当的使用复用可以改善系统的可维护性。

传统的复用

　　1.代码的剪贴复用：最初步的复用，每块代码分散在各处，独立的演变，仍需要针对每一块修改和测试。这种复用带来的好处很有限。

　　2.算法的复用：在已有的成熟算法中选择一个比自己重新开发一个好的多。比如排序算法。这就是算法的复用。

　　3.数据结构的复用：比如队列、栈、链表，在实践中得到了大量的应用。

传统的复用种类各有优点也有各自的缺陷。

可维护性与复用的关系

　　传统复用方案的致命缺陷是复用常常以破坏可维护性为代价的。

　　因此我们要支持可维护性的复用，即在保持甚至提高系统的可维护性的同时，实现系统的复用。个人感觉，旧有复用方式的缺陷是为了复用破坏了可维护性，或者说支持那些维护性差的复用。归根到底是因为，将不应该复用在一起的东西复用在了一起。设计上就出现了混乱。良好的设计不应该出现这种后果。而现在我们仅考虑支持可维护性的复用。将相关的东西放在一起，不相关的部分即使看似相同可以复用，也不能这样做。因为这种可复用其实是偶然的，以后系统一旦变化，这种所谓的“相同”就消失了。不知道这个理解是否正确。