code review 是软件开发团队“共同学习，识别模式和每日持续”的过程。
常见的code review方式和问题：
一周一次，一次两小时
- 人的专注时间在45分钟左右，超过后专注力会直线下降，导致疲劳，并且效果 不好
- 基本上是照着git提交记录不断的切换着不同人来讲，对不同的人都是突然被要求讲解上一周或本周早先编写的代码
- 需要不断切换主讲人和听众的角色，加大头脑的负担
- 没有连贯性，特别是分批量多次提交代码的时候
- 这时候受检阅的小伙伴需要在检阅前重新花时间重新理解代码，要不然就可能在检阅时磕磕绊绊讲不清楚
- 不确定能review多少代码，也就不清楚需要回顾多少编写过的代码
拿着笔记本，找专门的会议室
- 笔记本上操作，不管是否远程，都会由于环境，快捷键，辅助性软件等原因导致效率低下或造成讲解者紧张与不适应
- 讲解详细流程或算法细节，听众在缺乏前置条件或上下文的情况下，理解困难
- 预约不上会议室导致code review延期或取消
- 上一个会议没有在规定时间结束
在实施过程中，经常会出现有些同学由于跟不上其他人讲解的速度（毕竟不是自己写的），或没有相关的上下文（例如刚加入项目的新成员），或由于提交没有经过很好的切分和组织，导致整个过程都处于游离状态，而code review的效果就打了折扣，渐渐变成一个流程，一个过场，一个习惯。
甚至因为有时约不到会议室，本周暂停，停着停着就再也不执行了。。。
我的Code Review
时间
尽量一天一次，或由于不可预知的原因，至少保证一周三次的频率
地点
在自己或其他小伙伴工位上
- 如果是6人以下，则一台电脑两个显示器（显示模式选择：“复制这些显示器”），围在主讲人背后即可
- 8人以内，则利用网络会议或远程工具，至少两台相邻的电脑和4个显示器基本能满足
- 10人以上：
- 如果都有耳麦，则可以同时加入网络会议
- 如果耳麦配备不全，则可以相邻几台电脑入会，其他人围在这几台电脑周边即可
好处
- 团队经过一天高强度的思考与编码，适当停下来，看看其他人写的代码，同时将自己的代码讲解出来，往往能获得一些意外的灵感，或许能解决自己面临的阻碍。
- 互相了解设计思路，获得更好的建议和进行思路重构，提高代码质量。
- 及时发现潜在缺陷，降低事故成本：如果这个时候发现代码的坏味道和一些需要改进的地方，代码审查结束后可以花少量时间进行更改。
- 促进团队内部的知识共享。
好模式和反模式
code review重点是团队成员共同识别模式。这里的模式指的是程序员编写代码的习惯，包括“好模式”和“反模式”。
好模式 富有表达力的类名、单一职责的方法、良好的格式缩进等等
反模式 那些令人迷惑的缩写、几百行的一个类文件、if-else嵌套等
团队成员通过阅读最近编写的代码，来一起识别”好模式“和”反模式“，既是团队成员之间相互学习的过程，也是团队整体达成编写整洁代码共识的过程。
好模式和反模式其实就是编程的好习惯和坏习惯。代码回顾应该侧重于识别编程习惯，而不是找bug。
代码的作者不是重点。不是要揪出谁的错误，而是大家一起成长，回顾过程是大家达成一致的看法，并接受过程。
总结
代码回顾的形式应该是每日持续进行的。因为只有这样，才能持续改进团队的代码编写水平。要想能让代码回顾每日持续下去，一方面要像上面讲的那样，不针对作者去找bug来去除”挑错“的紧张气氛，营造”识别模式“来”共同学习“的环境，吸引团队成员长期参与（应该是轻松愉悦的亮出代码，而不是每次code review时，代码作者都处于高度紧张的状态）；另一方面，也需要将每日code review控制在半小时以内。因为code review的重点是识别模式，而模式就是习惯，习惯在很少的代码中就能体现出来。
image.png
网友评论