写码容易,读码难:工程师,千万别重写程式码

作为 100offer 工程师拍卖的行销,我们常常和用户交流讨论,有一个话题经久不衰:工程师入职新公司后接手已有的程式码,怎幺处理?

大家都有一颗工程师的心,所以当他们到一片新的场地想做的第一件事就是,将旧的一切打掉重来。是的,他们决不会满足于简单的增加劳动量。

或许这种微妙的心理定位可以解释:为什幺工程师进入新专案后宁愿丢掉旧程式码重新写,也不愿意修修补补,他们认为旧程式码简直一团糟。

但是,事实上真是这样吗?你之所以认为旧程式码一团糟,其实是由一个基本定律决定的,那就是:写码容易,读码难。

为什幺你觉得旧程式码异常混乱?因为读代码更难

这大概就是程式码 Reuse 难以实现的原因,也可以解释为什幺你组里的每个人都喜欢用不同的功能将分割的字符串转换成一个数组。比起猜测旧的功能是怎样实现的,重新写一个自己的功能要简单和有趣多了。

作为这个公理的推论,你可以问问身边的工程师他们正在奋战的程式码怎幺样?「简直是一塌糊涂!」他们肯定会这样说。「我简直想打掉重来!」

为什幺认为程式码这幺糟糕呢?「看看这个功能,竟然有两页长!完全不知道这些东西为什幺在这里!完全不知道这些 API 是干什幺的。」他们会这样回答你。

写码容易,读码难:工程师,千万别重写程式码
漫画:读别人程式码是一种怎样的体验?

曾经, Borland 的创办人 Philippe Kahn 当初就是向记者们吹嘘: Quattro Pro 会比 Microsoft Excel 要好用得多,因为它是从头开始编写的,全部都是新的源始码!

但是,认为新程式码比旧程式码好简直就是荒谬。旧程式码是已经运行过的,测试过的。无数的 Bug 在被发现前都上线运行过,发现之后工程师们可能在花了好些日子才修复了这些 bug 。这种修复可能是一行程式码,也可能是几个字符,无数的时间和精力都花在了这些 bug 修复上。

当你决定抛弃这些旧程式码从零开始的时候,你也丢掉全部前任努力的结果。

新程式码一定比旧程式码好? NO,重写可能会带来更大的风险

对技术领导者来说,重写专案的程式码代码也是一个异常艰难的决定。因为从公司层面说,重写程式码甚至会威胁产品的市场竞争力。一旦决定重写程式码,那幺与竞品相比,你可能落后了 2~3 年——在软体行业,这时间可够长的。

写码容易,读码难:工程师,千万别重写程式码
你理想中的新程式码会带来产品功能的提升

但事实上,即便重写的新程式码可以实现旧程式码的所有功能和需求,但是为产品带来的市场竞争力只有边际提升。因为重写用的新技术、新语言、新框架并没有给产品带来质的提昇。

更不用说在重写的漫长过程中可能会遇到一些意外情况,比如:

1、缺钱:资金鍊的断裂

写码容易,读码难:工程师,千万别重写程式码

2、缺人:核心工程师离职

写码容易,读码难:工程师,千万别重写程式码

最终导致效果不佳:达不到原产品应有的所有功能和需求,白白浪费了时间和金钱,也丢掉了市场竞争力。

所以重写程式码意味着,你在把自己置身于非常危险的境地,可能几年后你也写不出比以前更好的代码。你只是花了一大笔钱把已经存在的程式码又写了一遍。

当你觉得眼前的旧程式码很烂时,该怎幺办?

你觉得旧程式码写的很烂,那又怎样呢?它们已经上线,已经在实际运行中承受住了考验。所以当你发现前任留下的程式码乱七八糟的时候,不妨冷静下来,从以下三个方面入手理解程式码、改善程式码:

1、程式码的结构有问题

如果一段网路程式码突然弹出了自己的对话框,应该是 UI 程式码需要被处理。这些问题可以被解决掉,你要一次次小心地移动程式码,重构,改变接口。还需要一位细心的工程师立马仔细地检查这些改变是否有问题,从而不打扰到其他人。事实上,甚至比较大的结构变化也可以不扔掉代码程式码来完成。

大牛工程师 Joel Spolsky 回忆说,曾经在某个专案中,他和他的团队花了好几个月重新架构在一点上:把程式码动来动去、清理、创建有意义的基类,并创建了模块之间的完美接口。但是他们始终非常小心翼翼,并没有产生新的 bug ,也没有丢掉任何旧程式码。

2、程式码的效率不高

曾经, Netscape 的渲染程式码被传非常缓慢。但事实上,这只会影响该专案的一小部分,这部分是你可以优化甚至重写的。你完全不必重写全部程式码。优化速度的 1% 工作量,会让你获得 99% 的爆炸性提升。

3、程式码写得很丑

有些程式码真的写的很丑,比如 Joel 曾参与一个专案,开始用下划线做开始的成员变量协定,但后来改用更标準的「M_」。所以一半的功能用「_」开始,一半用「M」开始,这看起来真的很丑陋。但这个问题 5 分钟就能解决,而不用从头开始写全部的程式码。

最后,你要记住,从头开始再写一遍并不意味着你会写出比以前更好的程式码。因为你没有参与到上一个版本的建立,所以你其实根本就不算有经验。一旦你準备打掉重写,你可能会再犯一遍版本一犯过的错,甚至会产生更多的新问题。

总结

面对糟糕的旧代程式码 Keep Calm & Carry On!

在大型商业专案中,打掉重来是非常危险的行为。当然,如果你是在做实验,想到新算法可以随时重写。如果你跳槽、或刚接手一个新专案,面对看上去异常混乱的旧程式码,请冷静下来,忍住打掉重写的冲动,想想上面这些经验之谈。

《》

上一篇: 下一篇:

相关推荐