接手别人代码可能是继改bug之后程序员最不喜欢做的事情之一，特别是没有注释的代码。
道理我们都懂：优秀的代码应该本身自带注释，但问题是现在很多优秀开源的代码注释极少。
国内软件开发环境绝大部分都是赶出来的代码，这是行业内人人心知肚明的“潜规则”，主要考虑还是短时间内能够完成功能需求，老板上级甲方催得紧，能在规定时间内把需求搞完就算很不错的了，更别说是文档和注释了。
尤其是文档，很多人喊着骂前任程序员写的程序代码没有留下文档，但自己写的代码也不留文档，在这种大环境下独善其身也很难。
据说每一家公司都有一部分的代码已经成为了死穴，IT权威机构StandishGroup 在1995年的一项研究表明，只有大约17％的IT项目被认为是“完全成功的”，52％属于“勉强合格”（没有达到预算、质量或时间目标），30％是“失败的”。
最近，Standish对2003年至2012年期间的3555个IT项目进行了调研，这些项目的总成本至少为1000万美元，而仅有6.4％的IT项目成功。
这些瑕疵代码虽然外围功能使用起来没有多大问题，磕磕绊绊也能运转，但里面的代码结构混乱成一团，由于互相调用的次数太多，加上当初设计代码的人已经离职，后来的人由于板块涉及太多也没法动弹，干脆眼不见心不烦，人人假装没看见。
但这毕竟也不是长久之计，这些剪不断理还乱的遗留代码该如何处理？
首先当然还是以大局为重，要保证原有功能的稳定使用，在刚接手代码，对前人整体的设计思想以及理念都不清晰的状态下，维稳是第一要素，不能一下全部摧毁式重建，先尝试看看，做局部功能的修改，时间长了真正搞明白了再去做大规模的调整，选择一个小的初始目标来熟悉新工具。
随着时间的推移，它会变得更容易，但是切不要操之过急。对于这种棘手问题一定谨慎再谨慎，本就摇摇欲坠的大厦不能因为你而崩塌。
告诉你一个行业中没有公开的小秘密：大规模的重写通常会将一堆乱糟糟的代码换成另一堆。所以年轻人不要想着一口吃个胖子，在老板面前表现一番，重建代码，往往结果会很打脸，别问我怎么知道的。
其次，要搞清楚接手的代码在整个公司中的地位以及前景，代码的功能需求是什么？如果有文档的话，具体有哪些？ 通过跟踪bug，了解哪部分代码更脆弱。依赖的外部资源有哪些？如果已做了测试的话，具体包含哪些测试。
该软件的意义多大，对它的代码库的大小有个预估，同时对代码的优劣程度打个分，如果是写的框架比较差，同时还是未来主打的一个方向，就需要严肃对待，准备出一段完整的时间对代码进行重构。
所谓重构，即在不改变行为的情况下对代码质量进行一系列逐步改进的过程。要知道当你尝试修复代码时，同时更改其结构和行为是自寻麻烦。
挑主要瑕疵进行修改以便形成有效的代码块，同时未雨绸缪，先和上级主管做好密切的沟通，商议出重构的时间，并且做好代码重构的文档说明。
如果是没什么大问题的代码，就不要想太多了，简直是中**一样的幸运，可以直接开始慢慢消化学习，从基本的api接口学习，利用好测试模块代码，成熟的代码维护起来就不是什么问题了，以学习态度对待就可以。
然后才是重头戏，谋划和重构。
对如何规划你的应用程序有一个大致方向。也就是所谓的架构路线图，但路线图比较灵活，它会随着时间的推移而发生变化，需要根据情况作出相应调整。
应用程序的各个功能应当被拆分为单独的部分，以确保应用程序的各个部分都具有其专注的领域，因为这样它就更容易维护、扩展和重用，这也是我们想要修复遗留代码库的主要原因。
但是，这一阶段最好不要制定太过详细的计划，相反，只需确保你对大方向有一个粗略的认识即可，计划没有变化快，总会遇见难以预料的麻烦坎坷。
在测试过程中更建议的是集成测试，而不是单元测试。因为对于遗留系统的大规模重构，当你刚开始重构时单元模块会发生很大的变化，但集中在静态接口上的集成测试则不会。你想花时间重构你的应用程序，而不是你的测试，所以在你稳定代码内部工作之前，单元测试可能会分散你的注意力。
集成测试的优势在于，你可以一次覆盖大部分代码，如果正确完成，可以非常快速地编写。此外，对于结构不良的应用程序，单元测试可能很难执行。集成测试还有助于发现单元测试无法发现的错误：不同组件具有不同期望的错误。
而且当你有一些基本的测试来防止最坏的错误时，重构会容易得多。同样值得注意的是，如果你在此之前很少甚至没有做测试，如果你有一些可靠的测试，就不会那么糟糕。
总之是一个查漏补缺的过程，如果有文档就学习，没有文档就给补上，代码质量很差就想办法重构，接手别人代码在编码生涯中非常常见，要懂得集各方所长，融合各种可能，懂得变通，这是作为一个程序员的基本能力。
虽然我们不写烂代码，但遇上烂代码也是没在怕的，自己负责的模块就有责任和义务优化，可以循序渐进的去重构，然后在新的版本发布的时候带入进去，代码就是自己的脸面，毕竟代码质量不好，影响的是自己的形象。
如果你热爱重建代码，有着过人的技术和热情那也无可厚非，但是如果你在纠结是重建还是重构一段他人遗留的代码，请从重构开始做起，这种方法是一种成本相对较低且风险也较低的方法。
即使最后证明是行不通的，你可能会冒很小的风险。相反如果选择重建，你可能花费大把的时间精力最终仍达不到理想结果，在这个问题上，方向比技术重要。