cto进化手册：这屎一样的代码是谁写的

cto进化手册：这屎一样的代码是谁写的所谓的成长就是，当你回看曾经你写过的那些说说，会发现当时的那个自己怕不是个SB？从另一个角度抽离出来看这个问题，这往往代表着：此时此刻的这位研发，比起彼时彼刻的那个研发，变强（秃）了许多。正如我还在使用 QQ 空间的那个时代写过的一条说说：没人做声，后来 CTO 排查了一下 git blame 发现，这坨代码是他自己提交的。这样的地狱笑话在研发的职业生涯里实在是过于常见，以致于衍生出了各种版本，比如：当我写下这行代码时，只有上帝和我知道它是啥意思。现在，只有上帝知道了。

系统出 Bug 了，CTO 拉着开发一起检查遗留代码库，试图手动修复。

在经历了无尽的折磨以后，他们都崩溃了。

“这屎一样的代码到底是哪个哈麻皮写的？”

CTO 发出了震耳欲聋的灵魂拷问。

没人做声，后来 CTO 排查了一下 git blame 发现，这坨代码是他自己提交的。

这样的地狱笑话在研发的职业生涯里实在是过于常见，以致于衍生出了各种版本，比如：

当我写下这行代码时，只有上帝和我知道它是啥意思。现在，只有上帝知道了。

从另一个角度抽离出来看这个问题，这往往代表着：此时此刻的这位研发，比起彼时彼刻的那个研发，变强（秃）了许多。正如我还在使用 QQ 空间的那个时代写过的一条说说：

所谓的成长就是，当你回看曾经你写过的那些说说，会发现当时的那个自己怕不是个SB？

现代软件开发讲究团队合作，人员流动的来去自由带来了遗留代码库的维护问题。有的时候，代码写得跟屎一样，但就是能运行。有的时候，代码写得很漂亮，但就是跑不动。还有的时候，代码写得没毛病，但也没用，最后是靠 bug 运行起来的。

大多数时候，我们都建议，如果不是新加入的项目 owner，只是做一些小功能的迭代或维护，那么代码能跑的时候就尽量不要动。尤其是新人，正所谓新手一优化，系统就会炸，区别只在于什么时候。

很多研发在职业生涯初期，总是会有一种纯粹的工程师“原教旨主义”精神，代码追求极致的干净：严格的 lint 规则、命名模式、文件结构、不重复代码实践……尤其是在看到同事、项目前 owner 甚至 CTO 写的代码，总是喜欢跳出来杠一下：

这里为啥不对齐？我奶奶写的代码都比你强

我之前看过一篇文章，作者有次把同事提交的可运行的代码给重写了，理由是重复代码过多，经过他重写后的代码量级减少了一半，重复代码完全消失，他心满意足地提交了 master 分支，然后去睡了。醒来以后老板给他打电话，让他做回滚，他很不理解，却只能答应。多年以后回想这段故事，他才发现老板是对的。

理由是：

• 一，没有跟同事沟通讨论，就直接做了重写。这既没有真正领会代码作者的原意，也破坏了团队协作的信任基础，负面影响很大。
• 二，干净的代码在复杂的业务环境下，未必能实现原有代码的功能。减少的是代码行数，牺牲的可能是灵活性，反而不美。

他最后学会的一个道理是，在思考什么是干净的代码，什么是坏代码的时候，想得更深一点，是看中代码的优雅、美丽，忍受不了杂乱的状态，还是更应该关注工程实现的结果？

写出干净的代码不是终极目标，它只是处理系统复杂性的一种尝试方法，仅此而已。

回到屎一样代码的这个故事，Reddit 上的讨论其实非常热烈，我简单摘抄几条给大家看看：

• 我掉到这样的坑里太多次了，导致现在的我只要看到屎一样的代码，都会先说这肯定是我写的，没别人了。
• 通过读我自己写过的代码，我才真正明白：写代码远比读代码容易理解。所以我不再像个大明白一样 coding，而是开始思考如何让跟我一样的大明白们能读懂我写的代码。
• 代码写成这样，一定有这样的原因的。如果你打算对遗留代码动手，试着先去理解一下上下文。一开口别人是二傻的，往往自己先是大傻。

那么今天的研发小故事我们就聊到这了，回想你自己的 Coding 生涯，有没有哪些值得称道的大明白时刻可以分享一二吗？

我是 IT 之眼，下期再见