代码的持续可用性

代码的可维护性这个话题已经提了很多年了，但从最好的方案其实只是最适合自己的方案的角度思考，代码的可维护性说成代码的持续可用性更现实，更适合我们的目标。

代码的持续可用性说的是今天写的代码可以适用未来的需求，相同的工作不需要重复做。

但是，明眼人看到这里肯定会笑了，这是一个看起来不能实现的目标，在软件这个行业摸爬滚打过的人，谁不是在重复写东西，实际细节中各种猥琐的问题，怎么可能用去年写的代码来应付。

 

好吧，为了实现代码的持续可用性，需要从两个方面着手：组件和框架。

 

oo是个不错的东西，多态是个强大的工具，但是，建筑工程的经验告诉我们，拼装积木更适合人类的原生思维，在工程中组装是件较容易完成工作。好吧，这就是泛型，值得深入研究的一个具体模型是C++的template。核心组件开发完成，后期使用就是对核心组件的拼装。

 

但工程之所以为工程，是因为它的规模比较大，远远超出了练习题的范围，一个直观的说法是代码量，面对海量的代码，拼装积木的方式真的见效吗？这个时候需要框架，一个框架定下来需要坚持，而且不应该因为patch而被修改，这要求框架的设计比较完美或者持续的渐进完善，这种对框架的渐进开发是值得的，因为这样可以使得代码持续可用。

 

一个欲从事软件工程的学生，需要有一些基本功，譬如组件。也许组件做不了大事儿，但万丈高楼都是由组件堆积而成的。

 

一个膨大的项目，应该有一张合理的设计图，譬如框架，对框架的坚持使得组件的拼装思想清晰。

 

代码的持续可用的收益有很多，譬如有效回避出了问题牵一发而动全身的弊端等。