推荐 | 如何接手他人的项目代码（不限“工种”）
扫描二维码
获取更多精彩
嵌入式杂牌军
编辑|追梦星空
公众号|嵌入式杂牌军
在状态不好的时候不要过于强求自己，不然就是自找罪受（这话更适合自觉的人）。
文 章 导 读
在接手别人工程的时候会遇到这样那样的问题，今天就结合自己的工作体验说说如何接手他人的代码，难免有不到位的地，如有异议可以后台留言交流！
阅读过程中有什么问题可以后台交流哈，
！
1 接手他人代码存在哪些困难
不同的人编写代码有不同的风格和习惯，下面列举几项接手他人代码可能存在的困难。
1）代码风格问题
每个人撸代码的风格可能不同，这包括变量函数等的命名，宏定义、结构体、枚举、数组、指针等的使用偏好等都可能与自己不同的风格，程序封装的层次等问题。
代码如果曾经易手多人，更可能“气象万千”。
2）可能存在注释不完备及注释与代码不对应的问题
前面的代码编写者如果不喜欢加注释，或注释较少，接手的人势必会增加工作量。
如果前面的代码编写者没有及时更新注释，代码与注释不对应，这是会对让接手者产生困惑。
3）资料不多或不够完备
前面代码的编写者如果没有整理代码编写过程中的资料，资料比较少的情况，只能由接手者自己去找人要或上网搜。
4）代码比较大时，存在如何改写或重写的问题
如果只是简单的改型，动需要动的地，这到好解决。
但当代码比较大，要需要大量重写代码与已有代码进行对接使用时，就没那么容易了，这时一般先要理清现有代码，再结合现有需求进行分析找到省时省事又清晰的方式（当然实际中难免要纠结的）。
2 接手他人代码需要注意的细节
下面结合我的工作经历总结了20来个可能需要注意的点，为了方便小伙伴们阅读大致分了下类，难免有不妥的地方，望海涵哈，
！
1）资料收集
① 找相关人员。
接手他人项目有几种情况：
1> 现有同事需要做其他事务，领导将他手头的某些活交给你去处理。
2> 有人离职，同事走前的工作交接（时间上有限制，能整多明白就整多明白）。
3> 编写代码的人走了，其他人接手过。
4> 新人入职，干此活的人已经走了，其他同事不懂（这种情况比较悲催）。
前3种情况有最熟悉项目的人在，你要做的是两件事：问项目情况并要下相关的资料。
② 看相关文档或搜索相关内容做参考。
在资料不足或遇到看不懂的地方时，可以通过看相关文档或上网搜索的方式解决问题。
如果有人可以解答，在探究到一定程度之后再去向别人请教（在一个人问题上多思考，多深入，然后再问题是对被提问者的尊重，谁有那么多时间伺候你，要知道——这个世界不是你的老妈子），如果是很明确自己不能解决的问题，不要拖拉，直接去问，以节省时间。
③ 参照类似工程。
如果能找到类似工程，参考一下也是一种思路，但要协调好，寻找这类似工程的时间。
2）理清思路
① 大的程序如果不理清思路会陷入纠结中。
这是需要注意的一点提示，程序大的时候要定好是用现成的，还是重新定义重新写的问题。
② 理清函数调用关系。
大的程序一般都会多个函数去完成某项功能或实现某种操作），拿到程序后，你需要根据功能将程序的调用关系理清，每个函数是干啥的，可以画思维导图，也可以将主要的需要实现的调用关系汇总于文档中。
可能会花费些时间，但这样做目的性强，理解得快，后期还方便查看调用关系。
③ 先看主框架，如果有操作系统，先看任务函数。
查看主框架即主函数调用可以对总体功能由一个整体的把握。
如果有操作系统，工程中一般以任务为先进行功能划分，所以有操作系统，先看看任务函数，也能够以最快的速度了解整体功能。
④ 涉及比较大的协议可以画思维导图。
将协议的组成，数据关系用图的方式整理一下，整理的过程基本上就会对协议有一个不错的认识，后期也方便查看。
⑤ 程序分层。
对应函数的改写重新，不用动等的问题，也可以从程序分层大的角度去看，哪些层不用动，哪些需要重写，哪些需要做小的改动。
⑥ 决定是改写还是重新写，还是不用动。
前面如果你理清了函数的调用关系，那你就可以根据功能调用的线索，去看那些部分比较底层不需动，那些部分是上层应用，需要重新或改写。
⑦ 改写时是保留原有内容还是直接用工程改写成独立的项目工程。
要对代码做区分，可以稍微修改即可使用的函数是重新复制一版修改命名和声明（注意尽量要做一个项目中要统一，比如统一加上某个前缀或后缀），还是直接再原有代码的基础上修改，要尽快明确。
3）程序实现
① 画实现流程图。
修改或重写代码时，要理清实现思路，如果时间运行，可以画下流程图，对于特定函数可以用注释写好实现步骤，也可以在纸上写明实现步骤、方法、及注意点，先规划，规划的灵感比局限在点上时的灵感要好。
② 代码深入与否要做区分。
如果项目比较紧，要做好哪些需要深入，哪些只要会用即可，哪些需要深入研究后进行改写或重写
③ 尽量做好代码编写规划。
这个规划要有两点：一是时间上的规划，二是先写什么代码，后写什么的问题
写代码要有目的性（每找到一个点就弄清或做好实现计划）
④ 涉及操作系统的情况。
此时要理清实现优先级及任务初始化及任务实现中断处理等问题。
可以在理清函数关系的时候，将任务函数以及任务请求，事件标志等内容一并理清。
⑤ 边写边测试。
写程序过程中，加入新代码后要多测试，一是好查错，二是好定位功能性问题的所在。
测试可以通过打印信息，在线调试看变量值，将任务功能导向灯的闪烁或蜂鸣器的报警灯等方式进行。
多用打印或在线调试的方式，观察函数操作的中间值及结果值，有现象能促进理解，也能更快的对工程有个深入的了解。
⑥ 写好注释。
添加或修改的代码要做好注释，修改如有有必要可写明修改原因
新编写的函数要加好函数的注释头，如果写代码比较急可以将主要的名称功能先对应好，边写边写注释是一个好习惯。
如果时间比较赶，输入，输出返回值可能会有改动，在整体功能或工程完成时可以再进行修改，但一定不要忘记，一旦忘记后期再看代码时就会要花费更多的时间。
4）其他一些需要注意的细节
① 状态标志。
状态标志是一种软件功能开关标识，状态标志在理清程序可先暂时忽略，但在程序编写的时候过不可忽略，如果可以，在理程序的过程中也可以加入状态标志的判断逻辑，不过这样就太细了。
② 理清哪些数据需要写EEPROM。
程序最终处理的是数据，数据的赋值（输入）一般有：直接赋值和间接赋值两种。间接赋值要么是结构指针等的赋值（此时赋值至少分两次，有一必然是直接赋值），也可能是函数的返回值赋值，也可能是写入EEPROM，通过读函数读取后进行赋值。
③ 风格尽量与原有工程类似。
命名规则尽量与原工程尽量类似（如果原工程太出格，可以按自己的风格来）。
一个工程如果不遵守一定规则，易手的人越多，工程可维护性就会越差。
④ 不需要用的芯片功能可以先不看。
如果项目比较赶，现有代码能满足大部分实现需求，比如某些芯片功能代码，特别是各种配置寄存器的内容前期不用太深入，调用现有函数即可，不能满足要求时再深入手册去调整代码。
今天就到这吧，希望对小伙伴有所帮助哈，喜欢的话欢迎转发、点赞、分享、在看哈，
。