推荐 | 如何接手他人的项目代码（不限“工种”）-技术圈

扫描二维码

获取更多精彩

嵌入式杂牌军

编辑|追梦星空

公众号|嵌入式杂牌军

✎ 编者悟语

在状态不好的时候不要过于强求自己，不然就是自找罪受（这话更适合自觉的人）。

文章导读

在接手别人工程的时候会遇到这样那样的问题，今天就结合自己的工作体验说说如何接手他人的代码，难免有不到位的地，如有异议可以后台留言交流！

阅读过程中有什么问题可以后台交流哈，！

1 接手他人代码存在哪些困难

不同的人编写代码有不同的风格和习惯，下面列举几项接手他人代码可能存在的困难。

1）代码风格问题

每个人撸代码的风格可能不同，这包括变量函数等的命名，宏定义、结构体、枚举、数组、指针等的使用偏好等都可能与自己不同的风格，程序封装的层次等问题。

代码如果曾经易手多人，更可能“气象万千”。

2）可能存在注释不完备及注释与代码不对应的问题

前面的代码编写者如果不喜欢加注释，或注释较少，接手的人势必会增加工作量。

如果前面的代码编写者没有及时更新注释，代码与注释不对应，这是会对让接手者产生困惑。

3）资料不多或不够完备

前面代码的编写者如果没有整理代码编写过程中的资料，资料比较少的情况，只能由接手者自己去找人要或上网搜。

4）代码比较大时，存在如何改写或重写的问题

如果只是简单的改型，动需要动的地，这到好解决。

但当代码比较大，要需要大量重写代码与已有代码进行对接使用时，就没那么容易了，这时一般先要理清现有代码，再结合现有需求进行分析找到省时省事又清晰的方式（当然实际中难免要纠结的）。

2 接手他人代码需要注意的细节

下面结合我的工作经历总结了20来个可能需要注意的点，为了方便小伙伴们阅读大致分了下类，难免有不妥的地方，望海涵哈，！

1）资料收集

① 找相关人员。

接手他人项目有几种情况：

1> 现有同事需要做其他事务，领导将他手头的某些活交给你去处理。

2> 有人离职，同事走前的工作交接（时间上有限制，能整多明白就整多明白）。

3> 编写代码的人走了，其他人接手过。

4> 新人入职，干此活的人已经走了，其他同事不懂（这种情况比较悲催）。

前3种情况有最熟悉项目的人在，你要做的是两件事：问项目情况并要下相关的资料。

② 看相关文档或搜索相关内容做参考。

在资料不足或遇到看不懂的地方时，可以通过看相关文档或上网搜索的方式解决问题。

如果有人可以解答，在探究到一定程度之后再去向别人请教（在一个人问题上多思考，多深入，然后再问题是对被提问者的尊重，谁有那么多时间伺候你，要知道——这个世界不是你的老妈子），如果是很明确自己不能解决的问题，不要拖拉，直接去问，以节省时间。

③ 参照类似工程。

如果能找到类似工程，参考一下也是一种思路，但要协调好，寻找这类似工程的时间。

2）理清思路

① 大的程序如果不理清思路会陷入纠结中。

这是需要注意的一点提示，程序大的时候要定好是用现成的，还是重新定义重新写的问题。

② 理清函数调用关系。

大的程序一般都会多个函数去完成某项功能或实现某种操作），拿到程序后，你需要根据功能将程序的调用关系理清，每个函数是干啥的，可以画思维导图，也可以将主要的需要实现的调用关系汇总于文档中。

可能会花费些时间，但这样做目的性强，理解得快，后期还方便查看调用关系。

③ 先看主框架，如果有操作系统，先看任务函数。

查看主框架即主函数调用可以对总体功能由一个整体的把握。

如果有操作系统，工程中一般以任务为先进行功能划分，所以有操作系统，先看看任务函数，也能够以最快的速度了解整体功能。

④ 涉及比较大的协议可以画思维导图。

将协议的组成，数据关系用图的方式整理一下，整理的过程基本上就会对协议有一个不错的认识，后期也方便查看。

⑤ 程序分层。

对应函数的改写重新，不用动等的问题，也可以从程序分层大的角度去看，哪些层不用动，哪些需要重写，哪些需要做小的改动。

⑥ 决定是改写还是重新写，还是不用动。

前面如果你理清了函数的调用关系，那你就可以根据功能调用的线索，去看那些部分比较底层不需动，那些部分是上层应用，需要重新或改写。

⑦ 改写时是保留原有内容还是直接用工程改写成独立的项目工程。

要对代码做区分，可以稍微修改即可使用的函数是重新复制一版修改命名和声明（注意尽量要做一个项目中要统一，比如统一加上某个前缀或后缀），还是直接再原有代码的基础上修改，要尽快明确。

3）程序实现

① 画实现流程图。

修改或重写代码时，要理清实现思路，如果时间运行，可以画下流程图，对于特定函数可以用注释写好实现步骤，也可以在纸上写明实现步骤、方法、及注意点，先规划，规划的灵感比局限在点上时的灵感要好。

② 代码深入与否要做区分。

如果项目比较紧，要做好哪些需要深入，哪些只要会用即可，哪些需要深入研究后进行改写或重写

③ 尽量做好代码编写规划。

这个规划要有两点：一是时间上的规划，二是先写什么代码，后写什么的问题

写代码要有目的性（每找到一个点就弄清或做好实现计划）

④ 涉及操作系统的情况。

此时要理清实现优先级及任务初始化及任务实现中断处理等问题。

可以在理清函数关系的时候，将任务函数以及任务请求，事件标志等内容一并理清。

⑤ 边写边测试。

写程序过程中，加入新代码后要多测试，一是好查错，二是好定位功能性问题的所在。

测试可以通过打印信息，在线调试看变量值，将任务功能导向灯的闪烁或蜂鸣器的报警灯等方式进行。

多用打印或在线调试的方式，观察函数操作的中间值及结果值，有现象能促进理解，也能更快的对工程有个深入的了解。

⑥ 写好注释。

添加或修改的代码要做好注释，修改如有有必要可写明修改原因

新编写的函数要加好函数的注释头，如果写代码比较急可以将主要的名称功能先对应好，边写边写注释是一个好习惯。

如果时间比较赶，输入，输出返回值可能会有改动，在整体功能或工程完成时可以再进行修改，但一定不要忘记，一旦忘记后期再看代码时就会要花费更多的时间。

4）其他一些需要注意的细节

① 状态标志。

状态标志是一种软件功能开关标识，状态标志在理清程序可先暂时忽略，但在程序编写的时候过不可忽略，如果可以，在理程序的过程中也可以加入状态标志的判断逻辑，不过这样就太细了。

② 理清哪些数据需要写EEPROM。

程序最终处理的是数据，数据的赋值（输入）一般有：直接赋值和间接赋值两种。间接赋值要么是结构指针等的赋值（此时赋值至少分两次，有一必然是直接赋值），也可能是函数的返回值赋值，也可能是写入EEPROM，通过读函数读取后进行赋值。

③ 风格尽量与原有工程类似。

命名规则尽量与原工程尽量类似（如果原工程太出格，可以按自己的风格来）。

一个工程如果不遵守一定规则，易手的人越多，工程可维护性就会越差。

④ 不需要用的芯片功能可以先不看。

如果项目比较赶，现有代码能满足大部分实现需求，比如某些芯片功能代码，特别是各种配置寄存器的内容前期不用太深入，调用现有函数即可，不能满足要求时再深入手册去调整代码。

今天就到这吧，希望对小伙伴有所帮助哈，喜欢的话欢迎转发、点赞、分享、在看哈，。