“代码库就是每个糟糕商业决策的收据。”这是某个新上任CTO第一天打开代码仓库后最直观的感受。没有测试、部署让人心惊胆战、一个服务因为大家都不敢碰而几年没动过、数据库字段命名像火灾现场、TODO注释的年龄已经够投票了。工程师们说得没错，“需要清理”。

刚接手的技术负责人很容易掉进一个陷阱：立刻上手整顿代码。毕竟直观问题就摆在眼前。但真正该问的不是“代码出了什么问题”，而是“什么一直在让代码变成这样”。问题一换，视线就不再局限于代码本身，而是转向工作如何流入公司、谁有权推需求、哪些决策在不断制造遗留债。

打开网易新闻 查看精彩图片

烂代码从来不是一个糟糕的工程师造成的，而是时间线上铺满的商业妥协：为拿下企业客户赶出来的功能、销售不经工程评估就承诺的上线日期、两年前“临时”的变通方案、开发中途改了三次的产品需求、创始人直接在即时消息里丢过来的需求、必须在周五之前上的补丁。“先发布，后面再改好”，每一次交出去的技术债，代码库都记得清清楚楚。

承认代码质量很重要：烂代码确实会拖慢每个人，让简单的改动充满风险，让新人好几周用不上，滋生缺陷，把部署变成灾难，消磨优秀工程师的精力，同时让平庸的工程师变得危险。但如果只盯着“代码库有问题”而不去区分“代码库是根源问题”，就只是在治标。因为修完一次，组织依然会再次把它搞脏。