作者回复: 从点赞的数量来看,大家对这个问题是比较感兴趣的。我建议以下几个办法:
1. 团队统一思想,代码审查是有效工作的一部分,应该计算到工作量里面
2. 减少团体审查,选择更多使用工具进行1对1的审查。前者很难做到效率高。应该只是针对一些重点的提交采用这种方式。
3. 培训团队,统一认识,让大家了解到代码审查的长期收益,让大家不能不能只看到当前的开发进度这个短期收益,还要考虑代码可维护性以及后续添加新功能的速度这些长期收益。甚至可以坚持推动代码审查这个操作作为团队的制度。
后面的答疑文章我会作进一步的讨论。
作者回复: 解决的办法:
1. 让开发者代码在被审查的时候不被阻塞,还可以做其他的事情。比如我在第26,27篇文章中描述的使用git方式。
2. 审查者抽出一个时间段集中审查。
作者回复: 我在对一个比较长的方法进行拆分的时候。通常会先把。这个方法的,所做的操作。按照所做的工作按照步骤进行注释
==函数==
foo() {
ooo;
ppp;
qqq;
rrr;
}
==1. 把程序分成极大部分,添加注释==
foo() {
// Do something A
ooo;
ppp;
// Do something B
qqq;
// Do seomthing C
rrr;
}
==2. 把几个步骤提取出来,从而把foo()缩短==
DoSomethingA() {
ooo;
ppp;
}
DoSomethingB() {
qqq;
}
DoSomethingC() {
rrr;
}
foo() {
DoSomethingA();
DoSomethingB();
DoSomethingC();
}
这个里面关键在于第一步进行步骤的拆分。仔细对foo的工作思考,一定可以拆小的。
作者回复: 推荐听一下这篇:
14 | 质量与速度的均衡:让“唯快不破”快得更持久
https://time.geekbang.org/column/article/138916
作者回复: 这是因为通常一个功能可能会很大,如果一整个功能作为一个提交的话,提交可能很大,就像文章中漫画里的巨大星球一样 😀
做法是把功能差分成几个“子功能”,分别提交。比如说一个功能是提供一个API。如果这个API比较大,我们可以把它拆分成(数据模型+API业务)两个部分。如果这样下来还是很大,还可以继续拆小。比如API业务可以分成(refactor+添加新业务)两个部分。
总之,是把每一个提交都做成能够独立完成一些任务,但是有不太大。
作者回复: 很棒的思考!Git仓库对非常大的代码仓的确会有性能问题。不过追求原子性多产生的提交的量级应该不会太大,一般来说不会对Git的性能造成关键影响。而且每个提交变小了,也会抵消一部分多提交导致的性能下降。
作者回复: 评审意见数只能是一个简单的参考。
在Facebook,对代码评审工作的衡量,主要是通过同事间的主观反馈来获得的。比如我在文中举的例子,我的主管给我的两个反馈,一次是审查不积极,一次是审查太注意细节,都是其他同时反馈给他的。