潘凯的博客

这段时间花了很多时间在修改BUG上。有一些BUG可以看得出是以前的人在实现时仓促留下的。有时我们自己在巨大的时间压力之下也很容易会留下这种“缺陷”（可能当时还不是BUG），但是自己心里很清楚，这个地方在以后极容易出BUG。

实现功能往往是最容易的，保持代码的“干净”，架构的“纯洁”才是不容易做到的。

想想在一个版本反复的被测试打回，已经Delay了多日后，当修改一个BUG时，明明需要对架构进行一次重构，增加一个抽象。可又有多少人还会这样“大动干戈”，或者就把已有的代码COPY一下，再改一改就算了。越是在发版本的前夕，越是容易埋下“地雷”，留下隐患。所以我总是最担心最后改BUG那个阶段。

尤其对于我们这样的生命周期非常长，已经换了很多批开发人员的产品。不在代码中埋下“雷”，有时真得在很大程度上靠开发人员的自律。埋下去的雷就一定会爆，不是不爆，时候未到。出来混，迟早要还。快的就要自己去修补，慢的就由后面不好彩的接手人埋单。

有时在和同事一起review代码时，会讨论为什么一段代码需要重构，明明可以正常的运行。这时我会引入一个衡量的标准。如果以后有新的同事来维护这段代码，他会不会在心里骂人。其实我们自己在维护其他人写的代码时都会有这样的经历，有时你会在心里暗骂“靠，这是谁写的烂代码，浪费我大把的时间来调这种低级的BUG。”；也有时候你会由心里佩服人家写的代码，结构太合理了，扩展起来太方便了。不过我想一般是第一种经历居多。所以如果你不想以后维护你代码的人骂你，最好还是把代码写漂亮。

这个问题有时也有点像是在公共场合扔垃圾的问题。总有一小部分人会扔垃圾，然后另外一大部分人会觉得反正我不扔也会有人扔，如是也扔了，不过总是还有一些人不但自己不扔垃圾还会在公共场合主动的收拾垃圾。如果这部分人多了，社会就和谐了。

想起星爷那本《一个演员的修养》。在写代码的同时考虑到为以后会维护这段代码的人负责，我想也应该是一个程序员的修养。