接手别人代码是程序员最不喜欢做的事情之一，特别是没有注释的代码，优秀的代码本身自带注释，现在很多优秀开源的代码注释极少，但大家基本上都能服气的确代码质量高，但国内软件开发环境绝大部分都是赶出来的代码，主要考虑还是短时间内能够完成功能需求，能在规定时间内把需求搞完就算很不错的了，更别说是文档和注释了，特别是文档，很多人喊着前任程序员写的程序代码没有留下文档，但自己写的代码程序留下基本的文档的也很少，在这种大环境下独善其身也很难。 [原创文章：www.11jj.com]

[原创文章：www.11jj.com]

曾经在一家公司工作，有一部分的代码已经成为了死穴，外围功能使用起来没有多大问题，但里面的代码结构比较混乱，基本上上没人敢去触碰，由于互相调用的次数太多，加上当初设计代码的人已经离职，后来的人由于板块涉及太多也没法动弹。

对于遗留代码如何处理？

1.首先保证原有功能的稳定使用，毕竟刚接手代码整体的设计思想以及理念都不清晰的状态下，维稳是第一要素，先是尝试看懂代码了解代码，做局部功能的修改，时间长了真正搞明白了再去做大规模的调整。

2.搞清楚接手的代码在整个公司中的地位以及前景，同时对代码的优劣程度做出一个评估，如果是写的框架比较差，同时还是未来主打的一个方向，这个时候需要从长计议，考虑抽出一段时间对代码进行重构，使之真正成为有效的代码块，在这块就需要和上级主管做好密切的沟通，商议出重构的时间，并且做好代码重构的文档说明。

3.如果是非常优秀的代码，就不要想太多了，直接开始慢慢消化学习，从基本的api接口学习，利用好测试模块代码，，成熟的代码维护起来也会比较方便，以学习态度对待。

总之来讲接手前任代码第一要素了解各个模块的功能，如果有文档就学习，没有文档就给补上，代码质量很差就想办法重构，接手别人代码在编码生涯中非常常见，要懂得西纳百川，融合各种可能，这是作为一个程序员的基本标准。