チームの規模や上場しているかどうかなどによっても大きく変わるのですが、
コードレビューは誰がするかではなく、何を意識してコードレビューをするかをチームで明確にする必要があると思っています。
（ここでは監査関連の話や承認フローは気にせず、おおよそ5~10人くらいのチームの想定）
もちろん誰がという部分においても、エンジニアとして一定の知識や理解は最低限必要ですが、何を意識してコードレビューをするかの共通意識をチームできちんともってコードレビューすることが必要だと感じているので自分が気をつけていることを記載します。
今回はレビュアー、レビュイーのメンタル面に対するケアに関しては省略&別で書き残します。(大事)
意識する３つのポイント
可読性の向上
チームで開発するにおいて、可読性をあげていくことはほぼ必須です。
常日頃からメンバーが意識して開発することが大切ですが、レビュアーから指摘されることで気づくことも多いと思います。
- 無駄な処理を書いていないか
- メソッドにするなど共通化・抽象化できるところはないか
- 変数名など明らかにおかしいところはないか
ただ、可読性の向上を意識するあまり開発者の力量を考慮しない指摘やリファクタの提唱はナンセンスですし、リリース前日とかであればまずはリリースすることを優先して指摘をIssue化しておくなどの策をとることを心がけるようにしています。
バグを引き起こすコードの発見
どう見ても明らかにバグっていたり、動かないコードは論外として(そもそもPR出してはいけないレベル)
コーディングしている中で自分では気づきにくいバグを引き起こしそうな書き方をしているケースがあります。
そういう時はコードレビューで、冗長になっている部分を第三者の観点からすくい上げることができるといいかなと思っています。
また、コードの変更点(Diff)だけを見ていたとしたら、気づかないバグも潜んでいる可能性があります。
そういった見えない部分を俯瞰してレビューするようにしています。
技術知識の共有
既存のコードがすべて正しいということは全くなく、言語によっても変わりますが結構なスピードでデファクトは変化していきます。
エンジニアとしてアンテナを常にはり、技術のキャッチアップをすることは重要ですが、日々の業務に忙殺されて思うように時間がとれないということもあると思います。
ならそれをコードレビューの場を借りて解決していきましょうということです。
新しい知識をチームに還元していくことで、メンバーはそれを吸収しさらに強くなります。
もちろんそこで発生する新しい書き方を採用するかどうかの議論もチームとして大切なものです。
最後に
個人的にはコードレビューのタイミングで一行ずつしらみつぶしに見て、「この書き方はイケてないので〜」、「前も言いましたが〜」と指摘する必要性は時と場合によりますがないと思っていて、上記のポイントを全員が意識することでチーム全体のレベルが上がってくると思います。
レビュイーは最初から可読性やバグを引き起こしにくいコードを書く意識をもつようになり、自分がレビューするならこう指摘するだろうなという客観的な見方ができるようになってきます。
ここで述べた内容は本当に基本的なことなのですが、コードレビューに関するチーム内の共通認識は比較的ないがしろにしがちです。
特にレビュイーはレビュー時にストレスフルになりがちなので、まずはレビューの最低限意識するポイントをきちんと共有するところからはじめましょう！