那些坑爹的老代码，究竟改还是不改？！

在软件研发中，我们总会遭遇一个场景，就是要去改变或添加一项功能到既不是咱们创建、也不熟悉、更与自己负责的系统部分无关的代码中时，会遇到麻烦，而此时的内心更是崩溃的。

那么，面对前任程序员留下的代码，究竟要不要改？改写老代码，究竟如何才能不留坑？

曾刊载于《程序员》的《神秘的程序员们》漫画一则

长久以来，业界流传着一个约定俗成的禁忌：如果你恨一个程序员，就让他去维护年久失修的老代码吧！提到老代码，相信所有程序员都有话要说。

或许每位程序员都有一颗封疆扩土的雄心，所以入职后面对着冗余复杂的陈旧代码，很希望将一切推翻重来。毕竟代码结构 Bug、运行缓慢乃至于过于挑战审美等问题，很容易让人抓狂。但是对一家软件企业来说，老代码就是资产的象征，是多年积累下来的核心和重要竞争力。

对于软件产品，先后几波人维护过代码是很常有的事儿。如果你重写的新技术、新语言或者新框架并不能给产品带来质的飞跃，技术领导者又为什么要同意重写项目代码？更遑论维护过程中资金链断裂、核心程序员离职等突发情况的存在。

基于以上的思考，对于老代码我们究竟动还是不动？业内有赞同也有反对的声音：

@mostone：
动当然可以动，但一般一个项目的代码都比较庞大，如果耦合度较高，修改的风险必然很大。

@u013553804：
大刀阔斧，全部推倒重来，当无可奈何的时候。

@u012377333：
老代码能不能动，就看老代码写的怎么样了，比如一些开源框架，里面的很多基础的代码都不需要动或者只是简单的添加和新的业务逻辑相关的代码。如果老代码没有基于编码规范进行，里面势必就埋了很多雷，谁踩谁死。这里就涉及到一个问题，每一次代码合并必须要进行代码review，让该项目的所有开发人员对代码达成一致意见后，这样的老代码才能愈久弥坚。

@chinglish：
革命的时机未到你就去革命最终会革了自己的命；革命时机到了你再去革命那才真的是承天应人破而后立。

@dreaper126：
脱离业务需求，脱离上层的支持，脱离一个宽裕的时间段，切忌不要拆雷，成了没一毛钱好处，败了你就成千古罪人。

@汪海洋的博客：
变量命名没点数，有时写着还手误；界面全靠神奇数，保准看到就发怵；私有公有混一处，代理委托亦糊涂；消息通知满天飞，委托方法一大堆；第三方库无出处，随手改动无备注；单个对象多职责，悲伤逆向流成河；产品突增新功能，一行代码变大神；来了任务有委托，多写一行都嫌多。

对于老代码你有什么样的观点？欢迎各抒己见，在留言区分享你和老代码的爱恨纠缠。