【嵌入式开发学习】__Code Review 应该避免的几点错误

目录

前言

一、什么时候都要做Code Review?

二、Code Review主要是用来让别人检查Bug的?

三、初级工程师的代码需要检查Bug,高级工程师的代码不需要检查Bug?

四、Code Review提的问题越多越好?

总结语

(* ̄︶ ̄)创作不易!期待你们的 点赞、收藏和评论喔。


前言

相信很多大佬们,从刚开始工作时到现在,已经写了非常、非非常常多年的代码code,大部分“靓仔”的代码都会被人review过,就连自己也review了很多人的代码。

在我工作2年的履历,通过在工作/面试中做Code Review的过程,有一些自己任务错误的实践分享出来,也欢迎大家来一起讨论。

一、什么时候都要做Code Review?

Code Review是否一定有必要呢?我的答案是不一定

我觉得是需要分时间,分项目

在公司创业之始,1,2两个人吭哧吭哧的把整个产品从0到1的搭建出来,Code Review既没有条件(没有别人可以review),也没有必要,将产品实现,让项目活下来才是最重要的。

【嵌入式开发学习】__Code Review 应该避免的几点错误_第1张图片

在线上出了Bug,分分钟损失成百上千的时候,显然以救急为主,等Code Review黄花菜都凉了。当然这里分情况,如果是非常显而易见的bug,比如你非常确定是一个条件写反了,那么不用废话赶紧上。如果这个修改不那么轻巧,那么:

多一双眼睛看一遍往往会大大降低再次引入bug的几率。

二、Code Review主要是用来让别人检查Bug的?

将Code Review视为别人替自己检查Bug的手段,可能代表了相当一部分程序员的想法。

在Code Review中查错确实是一个重要的目的,但并不应该成为唯一的目的。【嵌入式开发学习】__Code Review 应该避免的几点错误_第2张图片

除了检查Bug,Code Review还是:

  1. 维持代码质量、统一代码风格的手段。每个人的技术能力,背景各不相同,放任自由的发挥可以写出很多质量不同,风格迥异的代码。通过Code Review,可以迫使大家将代码质量维持在大家都可以接受的程度,并且是的项目的代码风格尽量统一。
  2. 一个互相学习的过程。 对于初学者,我们可以指出其代码中的风格、设计等方面的不足,可以直接“教育”别人该怎么写代码。反过来,在Review别人的代码时,我们也可以学习作者是怎么写代码的,如何调用的API,用到了哪些设计模式。不仅新手可以向老鸟学习,老鸟们也有很多机会向新手们学习。我就是通过Review毕业的同事的代码学些的Java的JOOQ框架。
  3. 一个了解同事工作内容的机会。程序员平时可能会比较关注在自己的开发任务上,而自己的同事正在做什么,怎么做,这些信息通过Code Review可以最直观的了解。比如你的同事可能需要和你改同一个文件,这样你可以知道他改的思路,可以避免在代码合并之前产生冲突。

三、初级工程师的代码需要检查Bug,高级工程师的代码不需要检查Bug?

很多时候,对于初级工程师的代码,大家都会很踊跃的去review,并且会有以找到代码中的Bug而显示自己的“资深”的荣耀。但是对于高级工程师写的代码,要么人家根本不给你建Code Review,要么即使把你加到Code Review里,也碍于自己的地位不敢去提意见。或者大家都对高级工程师给予了充分的信任,对于他们建立的Code Review请求都不怎么仔细看,直接LGTM(Looks Good To Me)。

然而这是不对的, 初级工程师写小bug,高级工程师写要命的bug

【嵌入式开发学习】__Code Review 应该避免的几点错误_第3张图片

初级工程师做的任务也比较初级,而高级工程师做的任务也会比较重要。如果你去关注一下公司的重大生产环境事故,事故的引起者是高级工程师的可能性远远大于初级工程师。这和“出车祸的都是老司机”,“淹死的都是会游泳的”的道理一样,“高级”工程师由于专注于高屋建瓴的设计,反而有可能忽视了代码中的细节。同时“高级”工程师对于自身的技术信心较足,往往会忽视一些基本的自我测试等环节。

所以不论初级,高级工程师写的代码,Code Review都是必要的,只是侧重点可能会不同。

在检查Bug这件事上,我们在战略上相信同事,战术上要怀疑同事

四、Code Review提的问题越多越好?

我在工作中遇到过一些这样的“Code Review喷子”,同事提交了一段100行不到的代码,被洋洋洒洒的提了十几二十处问题。同事对在有些问题上回复了一下自己的意见,双方就一些萝卜白菜的问题盖了十几层高楼。结果两三天过去了,论战还在进行。

【嵌入式开发学习】__Code Review 应该避免的几点错误_第4张图片

我曾经在被这样“猛烈”的Code Review轰炸中,为了让所有的Reviewer都高兴,前后更改数十次,每次修改都有不同的同事提出各种各样的意见。并且最后关头为了一个设计上的分歧,将代码进行了大的重构,最终终于被接受(Accept)。然而代码合并之后却出现了低级的Bug,回头查了一下,正是最后一次的大重构引入了这个bug。为什么会出现这样的结果呢?一个Code Review进行的时间越长,Author的耐心越来越差,Reviewer也越来越只关注他们“希望”你做出的改变,反而属于捡了芝麻丢了西瓜。

如果一个Code Review中的提交太多,对于review过程是不利的。每个Reviewer的记忆是有限的, 可能只能记得第一二次代码的修改。如果一次Code Review中出现多个提交,审阅最新的提交则会丧失之前的上下文,则会出现我上面遇到的问题。

总结语

我们做Code Review的目的并不是追求完美的Code,世界上没有完美的Code,任何代码片段,只要足够长,都可以有可改进的地方。每个人心中的完美代码各不相同,有的人喜欢这样写,有的人喜欢那样写。在不违反前面说的代码质量、统一风格的基础上,应该遵守“谁写代码谁做主”的原则。


(* ̄︶ ̄)创作不易!期待你们的 点赞收藏评论喔。

你可能感兴趣的:(嵌入式开发,学习,代码复审,代码规范,嵌入式硬件,单片机,51单片机,stm32)