十年的老掉牙代码,你敢动

十年的老代码,你敢动?

十年的老掉牙代码,你敢动

你入职一家新单位,被告知需要维护一个老产品,经理找质管给你开通了svn权限,告诉你迁出哪个分支——就是那个十年前已经定型的分支,就是那个超过6代程序员维护过的分支——然后告诉你说,就在这个分支上改,添加一个新接口,以便支持H5 Video。

于是你开始看代码,云山雾罩,各种痛苦,完全搞不懂业务逻辑和代码的关系,也闹不明白这块代码为什么这么写那块代码是几个意思。你战战兢兢如履薄冰思前想后寸步难行。

你去问进来5个多月还没转正的老同事,他告诉你他也不懂,让你凑合着加个新接口实现了功能就行。加了新功能就行。

你去问干了快一年的资格更老的同事,他叮嘱你千万别动里面的代码,千万别管里面什么样,就在外面包一层,先交付新功能,其它的有时间再说,里面的逻辑十年没人动过了,没有一个人能说清楚怎么回事,你要是改,一不留神就遍地狼烟。

你怎么办?

怎样不让猴子吃香蕉

我想起来猴子吃香蕉的实验:

铁笼里关了五只猴,实验者放进一挂鲜嫩甜美的香蕉,五猴顿时兴奋起来,环视了周围,其中一只率先伸手去抓。这时,实验者以高压水枪冲击,包括那四只仅有念头尚未行动的,也受到了惩罚。

过了会儿,看看没有动静,水果香气四溢,又一只猴跃跃欲试窜到香蕉前,高压水枪的集体惩罚再次启动。如此这般几个回合下来,猴都变得老实了,眼睁睁看着令之馋涎欲滴的果实,竟无一只敢再尝试——因集体受罚的经验令之胆寒。

此时,实验者撤出一只水淋淋浑身发抖之猴,换进只新猴,这个不知天高地厚的家伙一进笼就奔 香蕉而去;这时,一种现像出现了:四只吃尽苦头的猴一拥而上,撕扯、阻挠这冒失鬼,不让它接近深具诱惑力的美味,以免大家跟着受罪。

至此,高压水枪这专政手段暂且搁置,威慑效果依旧。等猴子一只只置换完毕,五只新猴面对香蕉皆不敢造次,个个循规蹈距,成就了“自律”的一群。

在这个笼里一个奇异的景象出现了:猴们最爱吃的香蕉,成了“禁果”!

    ——2006年第 3 期 《随笔》朱家泰

关于老代码的禁忌

十年的老掉牙代码,你敢动

对程序员来讲,维护老代码是最恶心的事儿之一。没说的,就是恶心,公认的恶心,连我这种自认为随意、灵活、代码适应性强、没有原则的老程序员也觉得维护老代码是一种罪。如果你恨一个程序员,就让他去维护年久失修摇摇欲坠的老代码吧。

然而,本文开始时提到的情况却几乎是每一个程序员都会碰见的。老代码啊,我们恨之厌之烦之远之却不可弃之。对一家软件企业来讲,老代码就是资产,是多年积累下来的核心资产和重要竞争力。尤其是软件产品,一份代码先后几波人维护过是常有的事。

这种时候,老代码就老而成精有了生命,每当有新人进来,它都会用特有的超出我们耳力边界的高频发出声音:警告,警告,一波新程序员正在赶来,快给它们点厉害杀杀它们的士气。

而且,部分熟悉老代码的老程序员也会谆谆告诫我们,这几个文件不要动,这几个类不要动,这里一改就奔溃,那里一改就连不上服务器,雷区标识很多。还有那一进来就因为被告诫而根本就没看过老代码的程序员也会告诫我们,那代码谁也不懂,多少年没人动过了,不动为妙,免惹麻烦……

故事就这样发生了,禁忌就如此这般传承下来。我们知道那里可能有问题,可是没人敢去动它,等最后一个熟悉一部分老代码的程序员悠然远去,此地空余叹息,从此以后,新来的程序员就成了想吃香蕉的猴子。

动,还是不动?

老代码成了禁忌,我们往往被迫(没时间或不愿意或害怕或不屑)在漂浮海面的冰山的尖尖上修修补补,深入了解深层代码成了谁也不愿言说的痛。

然而都不懂看代码都不动老代码,老代码只能越来越老越来越陈腐,越来越没人敢动。越往后动的代价越高越没人敢动。这对公司和团队都不好。裹一层又一层,终将积重难返成为裹脚布,无人问津。

而一旦老代码没人能够把握,这些作为资产的代码实际上已经丢了,不再有价值增长了,原本领先的优势随着同行们百舸争流的追赶渐渐失去了。

这是对企业是一种损失。读程序员其实也是一种损失。

为什么这般讲?

情人还是老的好

程序员有个毛病:自己不写文档却老抱怨别人的代码没文档,而碰见了有文档的代码却又往往弃文档如敝履。所以,业界流传一句话:代码即文档。所以,业界的代码和文档,少见匹配的。

哇咔咔咔,对吧。

所以,我们只能接受这个现实:代码即文档。

所以,对维护老产品的程序员来讲,要想弄明白老产品的逻辑,就只要如下两个办法:

  • 找到熟悉产品的前辈,让他给你讲讲。如果你找了产品经理,他只能告诉产品设计上如何如何。如果你找了程序员,他通常会说就是这样那样,然后说一句高深莫测又拉仇恨的话:看看代码就明白了。
  • 自己啃代码,啃代码,啃代码。

Ok,维护旧产品,弄明白产品设计逻辑和代码实现逻辑是非常重要的。

对于本文一开始提到的问题,其实也可能有在外围包装的办法,比如你封装一个本地的HTTP Server,用旧API拿到数据作为HTTP流转发一下就能支持H5 Video标签了。也可能很多情况都存在折衷的替代办法。

然而,能弄懂代码是如何实现产品和业务的,还是有非常重要的好处——对程序员来讲很重要的好处:

文档是会过时的,代码是不会说谎的,读懂代码,你就真真正正明白了业务是如何实现的。对于没人敢动而又核心的老代码,你搞明白了,就占领了战略要地。

这里我要引用格力空调的一句广告词:掌握核心科技。不管这是吹的还是怎的,话说得不错,掌握核心科技才有竞争力,对程序员来讲也是一样,唯有掌握核心业务和代码,才能彰显自己的价值

除此之外,读代码也是非常重要的学习途径,尤其是经历过线上考验的代码,必然尤其过人之处。在阅读的过程中,我们可以学到很多东西,既可以学到业务,也可以学到设计。退一万步讲,即便你认为你水平远超一般人属于一针顶破天的那位,也还是可以从当时、当地的选择中学到东西:见贤可以思齐,见过可以自省。

所以,我的主张是:老代码,动啊,为什么不动!

不能拒绝时就接纳,无需排斥,何时何地都可以修行,只要有心,处处都是成长的机会。最不济,也锻炼了阅读代码的能力,庖丁解牛之技成了,也可以在将来以无刃入有间,发挥用武之地。

至于怎么读代码改代码,相信比学宋仲基撩妹容易多了,一句话:多读读就好了。当然展开来讲也可以有很多技巧,我后面会有一篇文章来谈。


相关阅读:

  • 为毛你深陷故障驱动式开发
  • 程序员的4种心态与4种将来
  • 大龄程序员的未来在何方
  • 程序员的能力拓展模型

更多程序员职业生活与发展的文章,请关注我的微信订阅号“程序视界”(programmer_sight):
十年的老掉牙代码,你敢动

7楼u012377333昨天 16:12
[quote=isaaccwoo]老代码的雷,我这个月就炸了好几个,问了问老司机,老司机说不要尝试拆雷——撞到雷一般顶多炸个车,拆雷却...[/quote]n这就是事实,除非排雷的比较厉害,能摸清楚所有的雷,不然还是重新找一条没有雷的路前进。
6楼u013553804昨天 14:45
大刀阔斧,全部推到重来,当无可奈何的时候
5楼foruok昨天 13:24
[quote=u012377333]老代码能不能动,就看老代码写的怎么样了,比如一些开源框架,里面的很多基础的代码都不需要动或者只是简单...[/quote]n是啊,是啊。有些老代码,经常需要鼓起勇气去重构。
4楼isaaccwoo昨天 13:12
老代码的雷,我这个月就炸了好几个,问了问老司机,老司机说不要尝试拆雷——撞到雷一般顶多炸个车,拆雷却可能丢掉自己的小命。n在老代码基础上修改,可能是采取“将错就错”的思路,如果基础库的某个属性顺序反了,很多人就在使用的时候也反过来用。而如果觉得以前的功能有错,就自己再写一个,于是乎,代码结构真的变得很臭。
3楼u012377333昨天 13:11
老代码能不能动,就看老代码写的怎么样了,比如一些开源框架,里面的很多基础的代码都不需要动或者只是简单的添加和新的业务逻辑相关的代码。如果老代码没有基于编码规范进行,里面势必就埋了很多雷,谁踩谁死。这里就涉及到一个问题,每一次代码合并必须要进行代码review,让该项目的所有开发人员对代码达成一致意见后,这样的老代码才能愈久弥坚。
2楼mostone昨天 09:48
动当然可以动:)n但一般一个项目的代码都比较庞大,如果藕合度较高,修改的风险必然很大。n所以,要看是什么人来改,你能不能担责,不然就等着被领导骂死了:)
1楼foruok昨天 08:43
[quote=mostone]动当然可以动:)n但一般一个项目的代码都比较庞大,如果藕合度较高,修改的风险必然很大。n所以,要看是...[/quote]n有道理,实际情况如此