作为一名程序员，处理别人遗留下来的代码应该是工作中遇到的最最最讨厌的事了。
毕竟每个人都有自己的开发习惯以及自己写代码的方式。
例如有的程序员写代码的时候，格式会不一样，换行的位置也会不一样等等。
若是别的程序员的代码不像是常见的dos,linux命令行之类的，在没有备注的情况下，是极有可能会完全看不懂的。
令更多程序员们苦恼的是，在工作中往往会碰到以下这个问题，尤其在新公司中：
即我们在改变或添加一个功能到不是我们创建的、我们不熟悉的、与我们负责的系统部分无关的代码中时，会遇到麻烦。
那么这时候你就可以使用下面的技术，确保在结束改动其他开发人员编写的代码时，有信心保持现有功能的工作状态，同时确保新功能与现有的代码库协调一致。
与编写代码的人交流
在涉及多个人的任何工作中，沟通至关重要。因为此时我们对现有的代码并不太了解，因此我们所了解的内容可能是被误导的，或只代表了其中的一小部分。
为了真正了解现有的代码，我们需要和编写它的人交流。
当开始提出问题时，我们需要确定问题是具体的，并且旨在实现我们理解代码的目标。例如：
这个代码片段最适合放到系统的哪里？
你有什么设计或图表吗？
我应该注意什么陷阱？
这个组件或类是做什么的？
有没有什么你想放到代码里，但当时没有做的？为什么？
与原作者密切沟通绝对是一个好办法，但我们应该自检不要太过于依赖于原作者。这不仅可能会惹恼原作者，还可能在我们的代码中产生无意识的耦合。
删除所有警告
对于未使用或添加注释的代码，删除它。如果我们稍后需要这部分代码，那么在存储库中，我们总是可以从先前的提交中检索它。
如果存在无法直接解决的警告（例如原始类型警告），那么使用注解注释该调用或方法。
这样可以确保我们对代码进行过仔细的考虑：它们不是因为疏忽而发出的警告，而是我们明确地注意到了警告。
一旦我们删除或明确地禁止所有警告，那么我们就必须确保代码保持免除警告。这有两个主要作用：
1、迫使我们仔细考虑我们创建的任何代码；
2、减少代码腐败的变化，现在的警告会导致以后的错误。
重构
在过去几十年中，重构已经成为了一个非常重要的术语，并且最近被当作是对当前工作代码做任何改变的代名词。虽然重构确实涉及对当前正在工作的代码的更改，但并非整个大局。
当我们重构代码时，我们必须要有方法来确保代码的外部可见行为不会改变。
为了确保我们没有改变系统的外部行为，每当我们进行改变时，都必须重新编译和执行我们的全部测试。
总之，接手前任代码第一要素，就是了解各个模块的功能，如果有文档就学习，没有文档就给补上，代码质量很差就想办法重构。 接手别人代码在编码生涯中非常常见，要懂得海纳百川，融合各种可能，这是作为一个程序员的基本标准。 本文作者：得程招聘
