这些老系统代码，到底是谁写的？

• 工期赶

• 练手项目

• 自起炉灶

• copy帝

• 怎么办？

小王新加入了一家公司，这家公司的历史悠久，已经运营了很长一段时间。由于公司的发展历程，公司内部存在很多老旧的系统，这些系统就像是一座座屎山，发酵已久，味道十分刺鼻。小王像许多程序员一样，被安排了修补这些屎山的工作，为公司的发展做出更多的贡献。虽然这些修补工作很辛苦，但小王一直都在努力，为公司的未来发展奋斗着。

在修补这些老旧的系统过程中，小王经常会遇到各种问题，有时候会感到筋疲力尽。他不禁会发出抱怨：“设计这个系统的人，真的是太差劲了！”。当然，设计这个系统的人，可能早就离职了，也可能就是小王的顶头上司。如果小王有幸获得一个脾气温和的前辈，他会带着无比后悔的口气告诉小王：“这个系统确实千疮百孔，如果我们当初按照正确的思路设计就好了”。

 

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

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

烂代码自有它的背景。

工期赶

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

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

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

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

 

练手项目

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

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

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

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

自起炉灶

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

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

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

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

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

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

 

copy帝

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

没错，他们是抄的。

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

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

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

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

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

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

怎么办？

后悔，可能是一种好事。这是相对于从不后悔的人而言的。后悔说明了他知道应该怎么做才是正确的，只是在某些特殊情况下，他的行动导致了不良后果。事实上，有过后悔经历的人在项目的时间和人员分配方面会更加谨慎。相比之下，从不后悔的人可能是固执己见，或者是真的认为自己一直是正确的，这是非常可悲的事情。

如果你不幸被指派去维护这些烂摊子，请记住要采取适当的措施，不要急于行动，也不要进行过度修正。除非你的团队真正获得了足够的时间和人员资源，否则铲掉这坨烂摊子只是一厢情愿。