开发同事辞职，接手到垃圾代码怎么办?

小王新加入了一家公司，这家公司有点年头，所以连屎山都是发酵过的，味道很冲。

和大多数时运不济的程序员一样，到了这种公司，做的大多数工作，就是修补这些祖传代码，为其添砖加瓦。每当被折腾的筋疲力尽，就忍不住鼻孔喷着浑浊的空气：“设计这个系统的人，真的是太垃圾了”！

当然，设计这个系统的人，可能早就离职了，也可能就是你的顶头上司。如果你有幸获得一个脾气温和的前辈，他会带着无比后悔的口气告诉你：“这个系统确实千疮百孔，如果我们当初按照正确的思路设计就好了”！

没有程序员不后悔过，就像亏钱的人都后悔买了股票，长大的人都后悔来到这个世界。

很多人看到烂代码，那都是事后来看的。在代码跑起来的那个时刻，“能运行”才是最重要的。烂代码能够进入仓库并投入生产，一定是某些环节的缺失造成的。

烂代码自有它的背景。

1 工期赶

有数不清的管理者，想要量化程序员的工作，由此产生了KPI、OKR这样的工具。在某个时期，它或许是有用的，但这种以截止时间点来衡量的工作方式，会造成技术债的大量积累。

在工期的压迫下，很少有人能够思考需求的合理性，以及后续的扩展性。烂代码在未经过Review的情况下，缺少重构、有限测试，就火急火燎的跑到线上运行。有些设计，可以说从源头上就是不合理的，但由于需要快速实现，方案上就不得不进行妥协。

大多数情况下，朝生夕死的代码并不会产生多大的问题。但总有一些项目，生命周期非常长，修修补补的需求还非常多。在一个地基不稳的地方造一座大厦，总有崩塌的一天。

不过管它呢，只要不是塌在自己手里就可以了。

2 练手项目

我甚至发现了一个非常有意思的现象。很多部门为了培养新人，会特意把一些非常重要的模块和功能，交给新人去做。

由于缺乏经验，新人在方案设计上有诸多的缺陷。但在时间成本上，它和老鸟相差并不太多。很多练手用的项目，在不经意间也会成长为巨无霸，然后它留下的缺陷就会被放大。

和大多数人的认知正好相反，新人在技术方案上，会采用更多的新技术和奇技淫巧，而老鸟善于使用最基本最朴素的工具来完成设计。这可能是一种想要把学到的东西付诸实践的功利心与追求时尚的虚荣心在作怪。

很不幸，追求技巧的代码，会有非常多的约定与规范在里面，如果不是项目统一把控，这种约定和规范会与项目中的其他约定和规范相悖，造成代码风格不统一，调试困难，无法扩展。

3 自起炉灶

很多程序员非常的自信，认为自己的english水平和编码水平特别高，表现在代码上就是龙飞凤舞，自起炉灶。

他们不去关心整个技术社区的约定和规范，在接口命名，对外API上倾注了自己过多的心血，我们通常把这些人称为东施效颦的轮子哥。

比如/health接口，我偏不叫health，我叫/server_status。

再比如错误码，我非要一个叫做 success_200，一个叫做fail_500。后续入职的修正帝看到这样的错误码，嗤之以鼻但是并不敢改动，于是他自己做了一套200和500。

这样的约定和修正约定，会在岁月的侵蚀下越积越多，以至于没人知道它是什么。

所以，如果你看到一个项目的代码非常的烂，不要着急修改，一定要按照它的烂逻辑写下去。相信我，它必定比你的修正稳妥的多。

4 copy帝

在很多公司，你去看他们的产品和代码，会有一种似曾相识的感觉。

没错，他们是抄的。

在缺乏产品设计和经费的前提下，老板下达了终极命令。

“照着xxx给我copy一个，连一个按钮也别放过”。

copy一个和设计一个是两个概念，copy通常意味着浅显的思考，在细节和功能上都比模子差了很多。

更要命的是，模子在变。如果运气不好，一个团队刚copy好了一个产品，结果第二天打开别人的产品一看，好家伙，人家全部改版了。

四不像和未经过设计的代码由此而来。

当然copy帝还指的是cv工程师，但他们的破坏力有限，初心也是好的，并不能造成多大的破坏力。

5 怎么办？

后悔，起码是好的。

这是相对于从不后悔的人来说的。后悔说明了他知道怎么做才是正确的，只是在某些特殊的环境中造成了这样的后果。

如果同样的轮回交给有后悔经历的人来说，他会有更多的思考在项目的时间和人员分配上。而从不后悔的人可能是倔驴，也可能是真的认为他自己是对的，这是非常可悲的一件事情。

如果你不幸在维护这些祖传代码，千万记得要做力所能及的事情，不要冒进，也不要过度修正。除非你的团队给了真正的时间和人员，来决定真正铲一铲。