源代码的寿命

jack

业务需求的变更让你必须回头修改最原始的EJB，你会怎么办？你会去修改你十多年前写的代码吗？或者花时间去分析其中需要修改的部分？或者干脆每次都新建一个新的小模块来解决？这些修改的代价是很昂贵的。

而现在的问题是：偿还这种“技术债”是正确的事，但是修改以前的代码一般都会比你上周写的或者上个月写的东西慢。如果以前代码应该修改的地方你没有及时去修改，这将影响你开发新的功能。最糟糕的是我们有时会明明知道有些地方我们做错了，但是还是保持他长期运行。这些方法在当时我们认为是对的，只是现在看起来是错了。

我们代码的寿命？

我对大量源代码做过调查，其中包括商业以及开源的，设计各种语言（Java，C#，Ruby）。总体上，这些代码都遵循一个相似的规则：

大约70%的代码，在你写后的12个月内一直在使用，没有发生修改。

也许并不奇怪，代码完成之后的头几个月改动是最频繁的。再往后似乎就进入了一种维护模式，改动量变得相对较少。

我发现这玩意儿实在太有趣了：大约75％的代码在我完成一年后仍然是原来的样子。你可以设想一下我现在对于这个问题理解了多少，想像一下那些早就忘掉的设计思想，改变了的架构愿景，新的工具和仍能重构使用的库。想像一下当年写下的那一行行代码在今天又能有多大的改进余地。而且，在那些仍然遗留着类似技术债的代码库里，就算我们一直在孜孜不倦地偿还，也没见到老的代码新了多少。

我是怎么做的这项分析？这要归功于Git的魔力，它使这项分析变得很简单。只要对整个仓库做一次git blame的递归，就能够列出针对分支中的每一行代码的commit号、提交人、提交时间。配合上一些shell脚本技巧就能得出每月或每天的统计数字：

git ls-tree -r -rz --name-only HEAD -- | xargs -0 -n1 git blame -f HEAD | sed -e 's/^.* /([0-9]/{4/}-[0-9]/{2/}/)-[0-9]/{2/} .*$//1/g' | sort | uniq -c

按月份统计，截止到今天，以上输出的这个表格是关于每一行代码最近被改动过的时间。不过，我也可以很容易地把时间往前推，比如把时间推到2015年的开始：

git checkout `git rev-list -n 1 --before="2015-01-01 00:00:00" master`

把时间往前推之后，重新递归运行一次git blame，通过比较每个月得出的结果，我就能知道有多少代码是在2015年之前写的。经过更加详细的分析，我也能得出某个月中最新修改的代码行数量怎样随着时间变化而变化，进而知晓代码衰退得有多快（多慢）。

结论

代码写出来无非是为了实现某个意图，递送一些商业数据，但很快这就变成一种负债了。年代愈发久远，原来的代码就越腐朽而越难以修改，根据上面的分析，你很容易明白为什么一个代码仓库能够存在将近十年之久，里面的代码为什么都是些老古董：每年的改动量少之又少，它们就是躺在那儿没人管，自始至终我们就只是在不断地往里面添加新的遗产——它们中的大多数即使到了下一个年头你仍然还是可以找到的。

对于这种情况，我们可以做些什么？过时的代码只会不断堆积，这似乎就是软件的自然法则，依我个人经验来看，即使大家齐心协力对这些代码进行重构，似乎也收效甚微。我们还能做些别的么？或者我们干脆坦然接受越是年代久远的代码就越难修改的这一事实？还是我们需要找到一个办法，鼓励软件有一个更短的半衰期，以更快地得到重写。