接手别人代码是程序员最不喜欢做的事情之一,特别是没有注释的代码,优秀的代码本身自带注释,现在很多优秀开源的代码注释极少,但大家基本上都能服气的确代码质量高,但国内软件开发环境绝大部分都是赶出来的代码,主要考虑还是短时间内能够完成功能需求,能在规定时间内把需求搞完就算很不错的了,更别说是文档和注释了,特别是文档,很多人喊着前任程序员写的程序代码没有留下文档,但自己写的代码程序留下基本的文档的也很少,在这种大环境下独善其身也很难。
曾经在一家公司工作,有一部分的代码已经成为了死穴,外围功能使用起来没有多大问题,但里面的代码结构比较混乱,基本上上没人敢去触碰,由于互相调用的次数太多,加上当初设计代码的人已经离职,后来的人由于板块涉及太多也没法动弹。
1.首先保证原有功能的稳定使用,毕竟刚接手代码整体的设计思想以及理念都不清晰的状态下,维稳是第一要素,先是尝试看懂代码了解代码,做局部功能的修改,时间长了真正搞明白了再去做大规模的调整。
2.搞清楚接手的代码在整个公司中的地位以及前景,同时对代码的优劣程度做出一个评估,如果是写的框架比较差,同时还是未来主打的一个方向,这个时候需要从长计议,考虑抽出一段时间对代码进行重构,使之真正成为有效的代码块,在这块就需要和上级主管做好密切的沟通,商议出重构的时间,并且做好代码重构的文档说明。
3.如果是非常优秀的代码,就不要想太多了,直接开始慢慢消化学习,从基本的api接口学习,利用好测试模块代码,成熟的代码维护起来也会比较方便,以学习态度对待。
总之来讲接手前任代码第一要素了解各个模块的功能,如果有文档就学习,没有文档就给补上,代码质量很差就想办法重构,接手别人代码在编码生涯中非常常见,要懂得西纳百川,融合各种可能,这是作为一个程序员的基本标准。