技术长青之路----代码维护

工作个几年，就会碰到代码维护的问题，温伯格先生在《理解专业程序员》中非常生动地描述了这个现象：

“”“

在一个只有三个软件公司的城市里，软件程序员X在公司A工作，工作了两三年，做几个项目，然后发现自己的大多数时间都是在为以前的项目修bug，X君觉得这样非常不给力，所以就跳到了公司B。在B公司工作了几年，又做了几个项目，然后又发现自己深陷在老项目bug的泥潭中，于是又跳到了公司C。同样的，过了几年，在C公司也陷入修bug的泥潭中。这个时候有在A公司同事联系，说公司招人，于是有跳回到公司A。

温伯格先生写到这并不是一个特例，知识在公司少的城市比较明显而已，而且有人已经开始了第二轮、第三轮的跳槽计划。

“””

再讲一个自己的亲身经历：

- 工作之初，被派去写一个硬件检测的程序，简单的说就是利用操作系统内的信息和SCSI命令获取的硬件信息，去检测硬件的改动。

- 颇费一番功夫(几个月)，折腾出来的一个版本，维护了几个月，功能渐渐稳定。

- 有一日，老大曰：美国一同事要接手这个程序，准备准备移交个他。于是把程序和自己的改进想法都移交给了同事M，美国同事稍微加了一些东西，代码量懂不超过5%.

- 后来，有中美几个同事合作，在程序检测信息的基础上，建立的后续处理的程序。期间，多次讨论改进这个检测程序，但都无疾而终（Ran out of steam）。

- 三年之后，参与工作几个同事（中美）纷纷各奔前程，老大（还留守）召唤我来修这个程序的bug。于是有机会在几年之后重新审视这段（青涩的）代码。

想了几天，总结了一下这里面的经验和教训：

- 从策略上来说，无论代码有没有移交出去，都应该关注自己工作过的项目，其中的得失，如果有力所能及的维护任务，要主动完成。自己就是在这个方面没有经验，加上另外的项目实在需要认真折腾，所以最后还是要话部分时间来维护这段代码，而且给人有不好的印象。自己曾经做过的东西和现在的东西，都是职业的一部分，是Reputation维护的一部分。你维护的不仅仅是一段代码，而且是自己的职业形象。

- 从技术上来说，设计时要主要代码的可维护性，低耦合-高内聚，这样就有利于重用性和维护性。我提到的这个程序，就是因为耦合太紧，所以要在上面做点什么改动实在太难，无怪乎三年内几乎没有人做过什么有意义的改动。

 

试想一下，如果要在一个公司呆上十年以上甚至几十年，并且有很好的声望（reputation），需要什么样的设计和代码维护技巧呢？