質の高いコードレビューをするために考慮すべき視点の洗い出し
どうせするなら質の高いコードレビューがしたい。しかし自分のコードレビューは質が高いものには程遠い気がする。 そもそもコードレビューにはどういう視点が必要なのか。自分に何が足りないのか知るべく整理してみた。
コードレビューの目的
コードレビューの目的を分類すると以下の2つになるのではないかと思う。
- 品質を上げる
- 組織内で共通認識をつくる
品質を上げるためのコードレビュー
製品やコードの品質を保証するためには以下の5つの視点でのコードレビューが必要ではないだろうか
- 仕様
- 可読性
- パフォーマンス
- セキュリティ
- バグがでそうか
仕様
そもそも開発が正しい方向性に進めているのかは重要だ。 開発に着手する前にある程度の仕様は決まっているかとは思うが、開発を進めているとどこか仕様が抜け落ちていたりする。 それが意図的なものでも意図的でなくとも、それが正しいのかという客観的なレビューは必要である。
可読性
可読性が重要なことは言うまでも無いと思う。 具体的には以下のような視点が考えられる。ぱっと思いついたものを挙げてみた。
- 設計思想に沿っているか
- 依存関係が複雑でないか
- コードを書くべきところに書かれているか
- PRやコミットの粒度は適切か
- 肥大化していないか
- スタイルガイドに沿っているか
- 一貫性があるか
- 命名がわかりやすいか
- typoがないか
パフォーマンス
具体的な手法は書くと長くなるので書かないが(そもそも理解できているとは言い難い)、そのコードが製品の動作を遅くしないかという視点は重要である。
まだきちんと読んでないが、具体的にどういうこの記事が参考になるかもしれない。 https://blog.jetbrains.com/upsource/2015/08/06/what-to-look-for-in-a-code-review-performance/
セキュリティ
今の製品のフェーズに必要なレベルのセキュリティを満たせているかという視点は必要だ。
バグが出そうか
バグがあるかどうかを実際に自分の環境で全て確認するまではしなくて良い気がするが、 バグを出さないために適切なテストコードが書かれているかや、コードが複雑になってしまっていないかなどのチェックは必要だと思われる。 ここは可読性と被る部分もある。
組織内で共通認識をつくるためのコードレビュー
コードレビューを行う目的として組織内で共通認識をつくることを挙げた。 コードレビューでは製品に使っているライブラリ、スタイルガイド、細かな挙動の仕様などを共有できるというメリットもある。
そうすると開発チーム内での話も進みやすいし、自分が開発している時に一度レビューしたコードが参考になることを思い出すこともあるだろう。
ネガティブになりうる要因
品質の保証や共通認識をつくるのに必要とはいえ、コードレビューはネガティブな方向にも作用しうる。 具体的には以下のようなことがある。
- コードレビューのタスクに時間がかかり開発スピードが落ちる
- レビュワーとレビュイーでのコミュニケーションがうまくいかず疲弊する。
- レビューがたまり、心理的な負担が大きくなる。
このネガティブな要因をいかに克服するかも質の高いコードレビューをするために不可欠だろう。
おわりに
ここではざっくり考慮すべき視点を洗い出したが具体的にどういう知識が必要か、どういう策を講じるといいのかもおいおい考えていきたい。
