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