职场中“祖传代码”的处理建议

程序员是如何看待“祖传代码”的？

祖传代码的由来

在实际的程序员工作中，祖传代码是常见的。因为真正的互联网职场生活中，业务变动调整频繁，每到一个新的业务线，第一件事就是熟悉现有工程代码，看旧文档等。而现有工程代码往往是经历了不知道多少人的迭代，修改，因此代码风格，逻辑往往千头万绪，甚至让人忍不住口吐芬芳。

如何正确看待祖传代码

但是现状就是这样，工作嘛，挣工资而已，既来之则安之，最后代码还是要落到自己头上来，毕竟你得在它的基础上修改不是？因此调整心态也很重要。我们能做的

1. 首先就是理清业务，明白大致的业务目标、流程；
2. 整理出一个属于自己的业务文档，从而熟悉业务；
3. 一边看代码一边整理出一个代码梳理文档，否则看了也白看，人是会忘的；
4. 从代码中抽取有益的部分，总结沉淀为自己的知识，取其精华，向其学习。从这方面来说，祖传代码也是“传家宝”，不是吗？

如何处理恶心的祖传代码

有些祖传代码就比较恶心了。所谓恶心有两种，一种是说它逻辑复杂，耦合业务非常严重，难以修改，或者说修改风险很高。另一种是说它代码有漏洞，有bug。

对于第一种情况，建议最好不要动！！！程序员届有种真理说法：只要代码能跑，就不要改一来你不清楚它涉及的业务有哪些，随便修改，后果未知啊。甚至是你觉得肯定没问题的修改，到了线上也会出现非常奇葩的意外，物理学都不存在了这种。这种情况很常见，你不要觉得奇怪，除非你是职场新人。二来，修改后如果出了问题，那么你就是第一责任人，等着背锅吧。这是很严重的，职场新人往往会在这方面风险意识不强，吃亏了才明白。因此这里给出这一剂免费的预防针。

对于第二种情况，如果你能看出代码的bug，那么你敢修复吗？修复后你敢承担bug修改后导致新的bug的风险吗？有点汗流浃背了吧。这种情况，建议是主动向组里抛出来问题，给出自己的方案，供大家讨论，至于是否修复，还是要看是否有业务收益。否则，还是那句话，不要修改，不要修改，不要修改！

以上就是个人对职场中祖传代码的浅陋观点，与君共勉吧