关于如何快速接手他人的代码

关于如何快速接手他人的代码
前言：
首先，我要说明下写这篇文章的目的，很纯粹，作为一个公司三年的“老员工”，其中两年半都在接手别人的代码，而且还都是功能已经写完的那种，其中还有没测试和评审过的，这心情只有过来人懂。接收别人代码在程序员的生涯里是难免的，在这里就是想写一些自己的收获和方法，让大家更快的去上手一份代码或者是公司的框架，不一定适用所有人，只希望能给大家一点点启示或者灵感，也算对得起这些年敲的键盘了。
正文：
1、准备
1.1明确接手的目的
首先，当你拿到一份别人的代码，你要自己知道目的，这是十分必要的，只有目标明确，你接下做的事才会有中心，才会专注，才会少走弯路，做事才会有效率，往往我们达到一个目的之后，离其他的目的也会很近，而且更快。比如，你拿到一份代码，领导下达的指令是在这份代码的基础上更换一个显示模块，那么，你的目的就是修改显示功能，学习这份代码的其他模块和框架不是你的目的，而是你达到目的需要去做的事情，你时刻要记住，你是要修改显示功能，除非其他事情阻挡了你的脚步，这样能更快的达到目的，当你开发完你要达到的功能时，你会发现，你对这份代码很熟悉，因为学习是模糊的，实践会使你清晰且深刻。
1.2 做一些准备工作
拿到代码后第一件事不是着急去看，而是先了解这份代码，先尽力找到相关的产品和软件设计相关的问题，这样有助于你更好的理解和阅读代码。产品设计相关的文档要先阅读，对这个产品进行一个大体的了解，有一个轮廓，这有助于后面代码模块的理解。然后是熟悉编程语言、代码框架，文件结构，编译环境搭建，遗留问题处理，找到代码设计方案，了解大致的工作量，如果有人能帮你完成交接，那恭喜你，你也一定要把握住他，这样可以在交接时完成一大部分准备工作，能少走很多弯路，比如，整理出你需要的东西，包括环境，代码框架和模块之间的关系，相关的设计图，别一个人逞强，什么都自己埋头干（如果你有时间的话除外），让他给你讲解，做到心里有个底，有交接的人帮助，为后面的工作节省时间，比如输出代码层面相关的东西，但是。
1.3接手代价
接手一份代码时，我们应该想一个问题，那就是值不值得接手，当然，这个问题在大多数时候是没有思考的必要的，因为没得选择。但是一个合格的程序员应该去评估接手一份代码的代价，当一份逻辑不清晰，没有注释，找不到作者的代码接手的代价是非常大的，其中隐藏的风险、你理清逻辑所花的时间、修改或者添加代码带来的问题、维护、修改标准等这些代价可能是你重新写一份代码的好几倍，这个时候你就有必要将问题提出来评估，找的一个最优的方案。
1.4 定一个明确的目标
目标是检验一段时间付出所得到的收获的量化标准，也是接下来时间工作的效率的评定，可以让你更有动力，及时的反思和调整，这个目标不必太大，但是要很明确，不能是很大很宽泛。比如你刚拿到一份代码，如果你的目的只是熟悉它，那么你将可能会花很长的时间随表浏览，没有规划，没有一个度量。结果可能就是花了很长时间去熟悉，结果要改一个小功能都需要重新熟悉一遍，才能理清思路。
正确的目的应该具体，就算没有，也要给自己定一个，比如新到一家公司，领导让你熟悉公司的代码框架，之后的产品开发都是基于这个框架的。领导给的命令是很宽泛的，熟悉代码的程序可大可小，很难衡量，容易自己偷懒找借口，这时候你应该给自己定一个很明确且具体的目标，比如一周输出几个模块的流程图、数据流图、时序图、函数关系链，或者是做一次代码分享，乃至是重构，这些详细的目标会让你有非常强的目的性，你的步伐就很快，这些目标的实现会让你非常有成就感和在你心里的印象更深刻，逻辑也更清晰，当你把看见的东西变成你自己的东西输出出来的时候，这东西真的就是你的了。相比宽泛的目标，明确的目标会使你更加有效率，更加的专注和心情愉悦。
1.5 环境搭建
当你要开始代码熟悉工作时，编译器是必不可少的，熟悉编译器的使用，特别是快捷键，能够让你快速的修改和测试代码，但是很多编译器的使用在你开始阅读代码时是不够方便的，比如存在函数查找局限性，函数关系不明了，无法直接跳转等问题，这样的会影响效率。当你开始阅读代码时，你需要有一个良好的阅读环境，比如Source Insight和Visual Studio Code代码浏览器，能够让你对代码的函数变量等一目了然，他能在你需要跳转和直到函数关联时让你一目了然，还有做一些批注，以及问题的导出整理，可以节省很多时间。代码浏览器的高效的阅读是几乎上所有IDE都给不了你的，阅读刚开始时很有必要使用阅读器浏览器。
2、方法
一份代码的接手，关键还是要靠自己，付出时间，耐心的去读和理解，这是别人帮不了你的。当然在这个基础上还有一些方法，能让你少走弯路，提高效率，每个人因为性格、喜好、目标和基础不同，需要根据自身情况选择一个或者几个最优的方法和消化他人的代码。
在这里先要说一声，当你需要开始接手别人代码时，那需要怀着一个谦虚的态度，要懂得海纳百川，没有人写的代码时完美的，加上每个人的风格和习惯不相同，他人的代码可能给你带来很多麻烦和糟糕的感受，但是你始终要怀着一个谦虚的态度去看，不要厌恶和立马想着重构，先看完，不要过早的下结论，可能理解功能后，你都写不出来，态度要端正，别人总会有东西让你学习的，你可能最后都会爱上它无法自拔，如果真的很烂，再想办法充公。也要放松心情，不要觉得会很难，别人都写出来了，能有多难，要相信你自己。
2.1 死磕法
死磕法，顾名思义，跟代码死磕到底，这不是一个贬义词，这是程序员要有的一种精神，当你消化一份代码，你绝不是单纯的只是想看看，或者直接拿来用，那这样就没必要看了，直接用，遇到问题的时候再去看，不然就有点浪费时间了。但是死磕法是有条件的，你的时间不是很紧，而且有深入的了解是你有必要的时候，你就要和代码死磕到底，解决你遇到的疑惑，不懂就查资料，问同事，直到你对这份代码了如指掌为止，我们在工作时需要有这种精神，他会使我们进步，不要遇到难题就绕开或者放弃，但是要善于利用身边资源和点到为止，不要陷入无限递归出不来，当到了底层驱动时，不是有必要，就往回看吧。
2.2 调试法
代码阅读能够使你很快的了解代码运行的逻辑和结果，但是难免出现不明白的逻辑和上下文不明了的地方，造成代码难以理解，如果你具备调试条件，那就需要运用调试的方式查看代码实际运行情况，这样能帮助分析，更快的正确理解。
还有一种情况，那就是在消化别人代码时，容易以自己的思维去理解，这样容易出现理解失误的情况，导致你后面的理解理解不同，这个时候也需要使用调试法进行一波分析，你会恍然大悟，感觉一切都联系上了，当然不是所有的代码都需要调试的，有很多代码可能很难触发，但逻辑简单，调试会花很多的时间，这是没有必要的。
举一个切身经历的例子，我在一次接手代码中，没有产品手册，没有软件和产品设计手册，也没有人交接，只有代码和硬件，当我消化代码过程中，看到了一处很重要的功能，但是我怎么也找不到这个模块的一个函数调用，全局搜索居然只有声明和定义，也没有指针引用，但这个函数如果没有调用的话，这个模块是不能正常工作的，但这个模块实际运行是正常的，这让我很难理解这个程序的逻辑，花了多时间也没有理解。于是我就打开了调试，发现该模块是有调用的入口，整个程序逻辑也清除了。
2.3 输出法
 个人认为输出法是最有效的代码消化方法，可以具体实施，也有量化标准。可以是在消化代码过程中输出具体的流程图、时序图、函数关系链，以及分享报告，输出东西可以多样化，但是目标只有一个，那就是你对这份代码的理解消化后输出属于你的东西，这正是消化的意义，吸收后变成自己的东西。
输出法在定义输出目标时，应该尽量详细，规定输出时间，不要给自己留有能力范围内的余量，应该尽量挖掘自己，这样一段时间后，你会发现，你已经能够对已经消化的东西轻易的说出逻辑和使用你已经掌握的部分。
2.4 重构法
重构法是一种消化方法，也是一种目的，当你想好要使用这种方法，你要做的不仅是对代码的理解，需要有对整个框架的深刻认识以及明确要实现的目标，因为每一次重构，不仅是对一份代码的整理，还是对整个功能的实现，模块之间的交互，后续的维护和移植工作的依次重构，这需要有明确的设计方案，才能减少后续因为方案问题做出的修改。重构法不仅需要消化整个代码，还要考虑到代码设计初衷，对自身有很高的能力要求。这种方法虽然前期比较花时间，但后期的维护和修改将会减少很多时间，这都是值得的。
 重构法不一定要对所有代码进行重构，不是为了重构而重构，而是为了代码能够更加实用、更好的传承和便于以后的维护，好的代码是可以继续使用的，也有些代码只要稍作修改也可以继续实用，这样也能减少重构所花的时间和减少一些问题的产生。
2.5 提问法
提问法是先找到问题或者是疑问，再去消化相关代码，必要时通过测试、调试等手段找到答案，一般用于Bug查找，代码走查、问题协助和合作开发，这种需要快速完成的工作中，提问法能快速的进入状态，这种方法的具体做法是，先明确问题，在从问题发散，找到尽可能的相关代码，通过消化这些代码，来一一排除相关代码，最终来定位问题代码，从问题代码找到问题的答案。
 提问法需要很多思考，从广到细，来理解这个代码，需要通过逻辑思考排除掉不可能的代码，排除的代码都是需要经验和推理的，不需要对整个代码都很熟悉，这样能够快速的消化目标代码和相关的代码。
2.6 测试法
 测试法往往用于熟悉某一段算法代码、一个函数和已经被封装的库函数，当我们需要使用，但是不想或者是不能知道这份代码的逻辑和实现，以及边值的执行情况，那么需要进行测试，来让我们去认识他，常用的是将代码分离，或者写一段测试代码，来确定代码的执行逻辑，加深对代码的认识，让我们能够放心使用或者是移植。
2.7修改法
 修改法使用与对快速的对局部代码的修改，当你需要快速的完成一个定制化项目的开发，而你又对这份代码很陌生，那么你就需要首先保证原有功能的稳定使用，毕竟刚接手代码整体的设计思想以及理念都不清晰的状态下，稳定是第一要素，先是尝试看懂相关代码，对无关的代码可有暂时不去了解，然后做局部功能的修改，时间长了真正搞明白了才能去做大规模的调整。
3、问题处理和思考
 消化别人代码的时候总是难免遇到问题，阅读时参考相关的软件设计文档是必要的，便于我们理解代码框架，陌生的代码就像一座没有灯的大厦，需要我们去探索，去了解每一层的结构和组成，当发现无法前进和前进困难时，要学会利用身边的工具和寻求帮助，一个人的能力和时间是有限的，在有限的时间做更有意义的事情才是我们应该追求的，相信总有一天，通过不断的学习积累，你会深入了解这座大厦，并创建自己的完美大厦，不求多高，多与众不同，只求多年以后，你依然觉得它漂亮。
 我们遇到的问题总是变化的，但是问题的本质是不变，那就是在等待你去解决，下次不再相遇，每个人都会遇到问题，但是要多一份思考和总结，不仅是积累，更是进步。
 努力和坚持，就会有收获，不停的学习，不仅会使我们进步，让我们在快速进步的信息时代不被淘汰，沉得住那颗浮躁的内心，才能稳步前进。