我是7-8个开发人员团队中的软件开发人员。我们已经进行了一段时间的代码审查,并且随着时间的推移,代码质量也有所提高。
但是我最近注意到,与其他开发人员相比,一些开发人员被要求进行更多的代码审查。恐怕是因为他们态度灵活。
在我看来,这不是应该执行代码审查的方式:所有团队都应对此负责,并且不应因为愿意接受更改而选择代码审查者。
您如何处理团队中的这个问题?
您是否建立了选择代码审查者的规则?
您认为代码审查者应该花时间进行(良好)代码审查而获得报酬吗?以及如何获得奖励?
感谢您的回答/想法。
我是7-8个开发人员团队中的软件开发人员。我们已经进行了一段时间的代码审查,并且随着时间的推移,代码质量也有所提高。
但是我最近注意到,与其他开发人员相比,一些开发人员被要求进行更多的代码审查。恐怕是因为他们态度灵活。
在我看来,这不是应该执行代码审查的方式:所有团队都应对此负责,并且不应因为愿意接受更改而选择代码审查者。
您如何处理团队中的这个问题?
您是否建立了选择代码审查者的规则?
您认为代码审查者应该花时间进行(良好)代码审查而获得报酬吗?以及如何获得奖励?
感谢您的回答/想法。
Answers:
引入一个规则,即不仅可以将错误分配给修复者,而且还可以将错误分配给修复者。那应该为代码检查创建正确的视角。
至于,
您认为代码审查者应该花时间进行(良好)代码审查而获得报酬吗?
好吧,我不确定开发人员除获得薪水并为自己所做的工作感到自豪之外,通常会因自己的工作而获得酬劳。但是,由于审阅代码是他们工作的一部分,因此审阅者应该花时间进行审阅,并以某种方式分享功劳。
您遇到的主要问题不是技术问题,而是某些工具可以减少代码审查所需的工作量。有一些挑战需要克服:
并不是说您不能使用SubVersion或其他工具(例如Fisheye)来提供帮助,但是Git管道与功能分支的内置集成确实使这项工作变得很轻松。
在工具之外,您需要研究更多的社会挑战:
也可能需要检查哪些类型的任务正在由敬业度较高的人员进行代码审查。他们可能会抓住所有容易的评论,这会使其他所有人感到痛苦。
一个好主意是按循环方式进行-选择一个对代码检查最少的人。随着时间的流逝,团队中的每个人都应该进行大致相同数量的评论。它也传播知识。
显然,偶尔会有例外,例如假期,那里会有高峰和低谷。
大三和大四/领导之间应该没有区别。应该对每个人的代码进行代码审查-无论他们有多高级。它减少了摩擦并有助于共享不同的方法。
如果您仍然担心所有这些检查的质量,请考虑为通过代码检查引入一套最低标准。您所包括的内容完全取决于您,但是您可能需要考虑的内容包括代码覆盖率,单元测试,删除注释掉的代码,度量,足够的注释,构建质量,SOLID原则,DRY,KISS等。
对于激励代码审查,质量代码是奖励。我敢肯定我们已经在次优的代码基础上进行了工作,如果另一位开发人员从一开始就对代码进行一次建议并提出建设性的建议,则可以大大减轻痛苦。
听起来团队缺少正式的代码审查流程。
我不是在谈论创建一个350页的Word文档,而是关于过程所需要的一些简单要点。
重要的位:
定义一组核心的审阅者。没有一般性陈述。命名人物。
这些应该是您的高级开发人员。
需要超过1位核心审核者才能退出该审核。
在每个sprint或发行版中至少确定另外一名非核心审阅者是临时核心审阅者。在此期间要求所有代码审核均退出。
项目#3允许其他开发人员轮流进入核心审阅者组。几周后,他们将在评论上花费更多的时间。这是一种平衡的行为。
至于奖励人呢?很多时候都承认一个人在整个团队面前进行代码审查时所做的努力可以奏效,但不要为此烦恼。
如有疑问,请定义流程,并告知团队他们需要坚持执行。
您可以尝试的最后一件事-可能引起争议:如果我可以使用成语,让@#$%成为粉丝。
让团队失败,因为未遵循代码审查过程。管理将介入,然后人们将改变。在您已经定义了流程而团队拒绝遵守流程的最极端情况下,这实际上只是一个好主意。如果您无权解雇人员或对人员进行纪律处分(大多数首席开发人员没有),那么您需要让某个可以这样做的人参与进来。
没有什么比没有改变事物的失败更重要了。尽管人们可能会说些什么,但您可以操纵《泰坦尼克号》,但要等它撞上冰山之前。
有时,您只需要让《泰坦尼克号》击中冰山堡即可。