
课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
软件编程开发代码评审是每一个软件开发项目都会经历的一个过程,今天南昌达内就通过案例分析来简单了解一下,软件开发代码评审都有哪些优化建议。
改动范围要小
每次评审的代码变动的范围,要保持尽可能的小。当一次评审的代码中,有超过3个,或者5个以上的关键变动时,就要考虑是否将其分解为更小的变更请求。
因为一次评审中,如果涉及到的改动越小,参与评审的人的认知负担也会更小,也就越能快速的评审、快速的给出反馈。
对反馈保持开放
关于反馈,无论是给与反馈,还是接受反馈,都是一样有压力的事。
编程是一门手艺,对于指出其他人努力工作的结果中,还有值得改进的地方,是非常不容易的。
如果你对你收到的反馈感到沮丧时,在做出回复前先暂停一下,也许把它先放在一边一段时间,去走走休息一下,再来处理结果会更好。
你对反馈意见越开放、越欣赏,你就越能从他人那里得到的极具价值的经验,你也就成长的越快。
快速的做出回应
如果你对他人的反馈,有消极的情绪反应,好的方式是先放一下。不要在愤怒的无意识中去回应代码的评审,至少要记住这一点。
如果你没有负面的情绪,就就尽快的处理反馈中问题,对代码做调整,以及提出一些后续的问题等等。
上下文切换是编码过程中精力杀手。我们的目标是尽可能的降低自己和参与评审的同伴的无效时间的浪费。
如果评审的过程大家能保持尽可能的同步,在一个场域能快速的完成一件事,那是好方式了。
切换到同步进行
通常情况下,大部分的代码评审是异步进行的,发起人通过代码评审工具发起评审请求,等待参与评审人的反馈……
现在,及时大家在千里之外的不同地方办公,也是可以借助于在线化工具,实时同步的开展代码的评审的。
在异步评审中,如果发起人对反馈有想法,也可以利用工具,将其转化为同步沟通,走过去,电话过去等等,都是可以提高效率的方式。
如果团队已经比较习惯代码评审,这完全可以开展同步评审会议:
1、作者概述评审代码;
2、评审者查看和反馈建议
3、作者对反馈做理解
4、作者对反馈做出反应
当参与在同一场域下,可以减少上下文切换的时间,很快的完成一项评审。
【免责声明】本文系本网编辑部分转载,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题,请在30日内与管理员联系,我们会予以更改或删除相关文章,以保证您的权益!请读者仅作参考。更多内容请加抖音太原达内IT培训学习了解。