推荐 | 如何接手他人的项目代码(不限“工种”)

嵌入式杂牌军

共 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,通过读函数读取后进行赋值。


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


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


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


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


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


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


相关推荐


代码意识——看代码最忌讳什么


宏定义中省略号在调试中的妙用


C代码实现数据通信中的转义与解析(一)转义


C代码实现数据通信中的转义与解析(二)解析


专辑分享


Linux专辑


C语言专辑


软实力专辑


软件推荐专辑



欢迎关注我的公众号,一起撸代码玩技术
浏览 97
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报