[SCRUM]让我们来谈谈如何进行代码复查。

>>[SCRUM]让我们来谈谈如何进行代码复查。

[SCRUM]让我们来谈谈如何进行代码复查。

众所周知,代码审查是软件开发过程中十分重要的环节,楼主结合自己的实际工作经验,和大家分享一下在实际工作中代码审查是如何开展的,

笔者水平有限,若有错误和纰漏,还请大家指正。

代码审查的阻力

我想不通公司不同部门对代码审查这项工作的重视程度还是不一样的,对于代码审查的阻力总结了以下几点:

翼发云敏捷项目管理系统是一个在线的研发项目管理软件,支持多人协同开发,提供移动研发项目管理app,旨在帮助软件研发企业进行更好的研发项目管理、软件开发流程管理,该研发项目管理软件内置了敏捷开发流程和软件开发流程,结合SCRUM思想,满足各种规模的软件开发企业的研发项目管理流程的需要。

  • 国内、国内的企业,尤其是互联网公司的整体环境,要注意速度,迭代软件开发周期短,速度快,因为竞争太大,产品的开发要求快速上线,代码审核不是很认真,第一行,一个问题要解决。
  • 一个公司的规模,一个大公司重视的过程,代码审查作为软件开发的一个重要部分,甚至一个检查,无论什么时候成为一个系统,都是比较容易开发的。小公司不是,特别是在开始阶段,代码审查可能没有必要。
  • 如果你没有一个代码审查系统,如果你的领导是一个技术来源,并且理解代码审查的重要性,你将被要求去做。如果它来自其他领域,可能没有意识到它的重要性,那么代码审查的意义就是浪费时间(也是代码重构的一个原因)。
  • 个人原因,特别是刚进入公司的人,似乎没有在大学软件工程课上引入代码评审。

代码评审的重要性

说了代码审查工作的开展遇到的阻力,下面说一下为什么代码审查是重要的。 软件项目管理就用翼发云敏捷项目管理系统。

  • 代码审查是保证代码质量的重要手段。软件缺陷可能隐藏在各个地方,测试是发现缺陷的一种重要方法,但专业的测试人员更可能是黑盒测试,他们不注重代码的内部逻辑,只注重功能的代码,有人说在代码测试的逻辑要求开发单元测试,另一方面,单元测试覆盖率是不可能达到100%,在所有其他方面,是单元测试,测试场景是简单的,一些复杂的场景可能会检测不到。所有的测试完成后,如果有缺陷,它只能让客户作为我们的“终极测试”,投诉就会随之而来,客户满意度越来越低。因此,我们必须考虑我们可以用来提高代码质量的所有方法,以及代码审查,测试不能发现的问题,或者您可以通过代码检查找到问题。
  • 代码审查是一个很好的方式来熟悉软件架构和理解软件的业务逻辑。学习代码是一个切入点。一百万行代码系统启动时,只需熟悉一个模块、一个模块、一个组件和一个组件。一个比较大的实现,不应该是唯一的开发者,系统架构师从系统设计输出,再到设计技术的输出,每个团队在组件层面上,要开始实施,应该把功能划分成不同的模块,与不同的开发者实现协同。这是一个学习的机会。不要只关注你自己。为了了解这个功能的大功能甚至功能,你还需要注意别人的工作。要看代码和漫无目的的浏览效果是不一样的,你要了解新的功能,在考虑代码前如何编写代码,和别人不一样的地方一样,新老功能是如何相互影响等等的,心,你的学习速度会更快,记忆更深刻。
  • 代码审查是一个改善自己的好方法。前提是团队中有经验的开发人员的存在。丹尼尔,别错过机会,让他看到你的代码,不要害怕他会为你挑选了很多问题写代码,有人说,你写的代码,就像自己的孩子一样,看不见的人说不的话,不要固执,平和的心态,客观的看在你写的代码,发现和解决问题才能提高自己。不要错过查看丹尼尔代码的机会,看看代码是由牛写的,你可以把它的精华取出来。
  • 代码审查需要权力。网上有帖子说,高级程序员的工作生活没有必然的联系,你有5年的工作经验,或5年的经验,这就需要你刻意练习的评估代码一开始你可能不习惯,也可能是很痛苦的,一个屏面码不知道如何。但一句话,如果你内心感到舒适,你就是在走你自己的路。感受你正在攀登的痛苦,试着联系他们的大脑,今天你看到一页代码可能用了一个小时,没问题,但一个月甚至三个月后,你可以一目了然地发现代码中的缺陷,祝贺你,你的技能加深了。

我们如何进行代码评审?

好了。罗嗦了半天。下面开始说一下在楼主参与的项目中是如果开展code review的。

第一家公司,是一家国内的大公司,就不说名字了,我所在的部门开发的产品众多,换项目很频繁,我参与的有3,4个吧,开发流程不规范,部门老大没有对代码审查有硬性要求。但带我的老师,也是项目经理(但是主要做技术,所以也可以说是技术经理)是一个非常热衷于技术的人,应该说明白代码review的重要性,我们敏捷团队有4个开发,每次写完代码后,都会进行team review。把代码投到大屏幕上,然后老师带我们去review代码。印象深刻的一次是一个同事着急回家过年,草草把代码就提交走人了,被师傅挑出来很多问题。换了项目和项目经理之后,代码review就不了了之了。 翼发云研发管理系统完整实现SCRUM敏捷开发流程

第二家公司,是一个外企,有几十年的历史了,开发流程算是比较规范了,而且分工明确。在这家公司我们的大老板(也就是技术经理的上司)对代码review是有要求的,下面详细说明我们的代码审查是如何一步一步演进的。

  • 第一阶段团队回顾+ tfvc

先简单介绍下我们的版本控制工具:微软的TFVC,代码的branch是按如下图创建的,有一个main branch每个 scrum team一个branch,出release之前把各个team的branch merge回main,最后出release branch,release branch上修复的bug也要最终回main。 SCRUM研发项目管理就选翼发云。

谈一下我们是如何开展code review的

开始的时候我们是没有peer review的,每两周开一次team review。一个主持人,负责预定会议室,操作visual studio查看最近两周提交的changeset,一个记录员,负责记录发现的问题,相关功能的开发人员负责讲解和解答疑问。最后记录员将review结果记录到wiki中并发送到整个开发部门。

  • 第二阶段自律tfvc +审稿+团队回顾

记不太清是从哪个visual studio版本开始支持code review了,好像是VS2012。在提交之前每个开发人员需要将代码提交给至少一个人进行review,然后生成一个code review的work item。你需要将这个work item链接到你的changeset中才能check in代码,不然我们公司自定义的policy会发出警告。这些警告是可以被忽略的,然后也能强制提交。前面说过部分老大对code review是很重视的,如何才能检查peer review的结果呢?对,将这些code review的work item数据进行查询,将没有链接work item的changeset过滤出来,然后将结果显示。技术经理和老大一眼就能看到谁没有遵守这个流程。尽管这么做了,开始执行的时候还是有不少的人出现在查询结果中。

说一下自律的问题,公司添加这个查询review结果的措施是手段,只是在某种程度上保证了流程,但目的是什么?目的是需要收到review请求的成员认认真真的review代码,而不是随便的走一下流程就OK。如果你认识到review的重要性,你可能会用心一点吧。

我们的team review 会议依然在进行,和peer review的区别就是peer review只给一个人或者少数的人进行review,而team review 是在整个 scrum team间进行。

  • 第三阶段Git +同行评审+团队评审

我们的公司虽然历史悠久,但对一些流程的工具和技术还是极力推崇的。大家都知道GIT是非常流行的版本控制工具,visual studio 2012也开始支持GIT,我们也一步一步的 将source code移到了TFS-GIT中。

和TFVC相比,GIT的branch是非常轻量级的,你可以很容易并且快速的创建一个branch。所以我们现在可以将branch进行细分了。TFVC和GIT的代码提交也不一样,TFVC是集中式的,最全的代码放在server上,你需要一个branch的code时要将其check out到本地。每次提交都是把代码从local一次性merge到server,如果出现conflicts,你需要在本地处理然后check in。GIT是分布式的,每个人clone的时候都会把所有分支download到本地,代码提交是通过pull request来进行的,也就是通过branch之间的merge来进行,这一点刚从TFVC转到GIT的时候很难理解。这样就得为每个人创建一个临时branch,注意这个branch在本地和server端同时存在,我们用这个branch开发自己的代码并用这个branch进行merge code。这里的pull request就相当于TFVC中的code review,TFVC你还可以偷懒忽略code review的work item,在这里就是强制性的了,没有pull request,别人不会approve你的代码,你根本就没有方法将你的代码merge到feature branch中。

还有team review会议也是照常进行的。

文章从互联网整理而来,旨在传播SCRUM、研发项目管理、敏捷开发管理工具的知识与应用,帮助软件开发企业真正了解SCRUM的价值和意义,如果本文侵犯了您的权益或者您需要具体了解更多国内做研发项目管理系统的公司翼发云敏捷项目管理系统的相关信息,欢迎和我们联络:

【网址】www.effapp.com

2018-04-22T18:01:32+08:002018-04-22 18:01:32|Categories: scrum项目管理|