エンジニア・チーム開発経験が5年以上ありますが、未だに「コードレビューは難しい」と感じています。この理由について、自分の中で言語化出来てきたので、それについてまとめます。
コードレビューの効果
一般的に、コードレビューは以下のような指標を満たしているかを確認するために行われます。
- 良い設計になっているか
- コードの可読性が高いか
- 求める要件を満たしているか
- バグがないか
- セキュリティ上の問題がないか
- パフォーマンス上の問題がないか
- テストの網羅性が十分か
- コードスタイルに一貫性があるか
- コメントやドキュメントが適切に書かれているか
これ以外にも、チーム開発において良い副作用を求めて行われることがあります。
- 技術的ノウハウの共有
- コード責任を複数人で分散する
- コードをメンテできる人数を増やす
- チーム内のコミュニケーションを促進する
非常に多くのメリットがあるため、コードレビューというのはエンジニア組織では一般的になっています。
これらのメリットを最大限享受するのは難しい
一方で、これらのメリットを最大限享受するのは難しいと思っています。 複数人の知恵を結集させることで、より良いコードにできることは事実ですが、これにはトレードオフがあります。
それは、「コードレビューによる効果」と「コードレビューにかかるコスト」のトレードオフです。 コードレビューは、短い時間で終わらせることもできるし、何時間もかけて丁寧に行うことも出来ます。そのため、コードレビューによる効果を最大化させようとすると、どうしても時間がかかってしまいます。
このトレードオフを考えながらレビューをするのは、非常に難しいと思います。
トレードオフを考えるのが難しい理由
コードレビューの指標が多岐に渡っている上に複雑
コードレビューの指標に関する記事は非常に多くあります。例えば、Google's Engineering Practices documentationには、以下のような指標が記載されています。
- 設計
- 機能性
- 複雑性
- テスト
- 命名
- コメント
- スタイル
- ドキュメンテーション
しかし、これらの指標は一つ一つが非常に複雑で経験のいるものです。 例えば、「リーダブルコード」や「良いコード／悪いコードで学ぶ設計入門」などの書籍でこれらの技術について説明されています。
Googleの指標を元にコードレビューをするにしても、非常に多くの知識が必要とされるため、コードレビューの効果を最大化させるのは難しいです。時間をかけ過ぎても良いコードレビューが出来ると限らないため、ある程度の時間を掛けたらレビューを切り上げる必要があります。
トレードオフのどのラインを狙ってコードレビューするべきかが明確になっていないことが多い
僕の経験はまだまだ浅いものの、「コードレビューで担保したいライン」が明確になっていることは非常に少なかったです。そして、このトレードオフについて議論されている記事もあまり多くないように思います。
このトレードオフは、時と場合によって最適解が変わるため、あまり公開の場で議論されていないのではないかと思います。
プロジェクトによって重視する指標が異なる
プロジェクトによって、どの指標を重視するかは異なります。 金融系のプロジェクトであれば、バグやセキュリティ上の問題があると利益やサービスの信頼に関わるため、非常に重くレビューされるでしょう。一方で、PoCやOSSなどであれば、多少バグやセキュリティの重要度は下がります。
こういった理由から、コードレビューのトレードオフのベストプラクティスを話すのは難しいでしょう。
人によってスキルが異なる
コードレビューを行う上で、必要なスキルを持っているかいないかは人によって様々で、良いコードレビューを行うためのコストは人によって変わります。そのため、「コードレビューは何分以内で終わらせる」といった制約を決めるのも容易ではありません。
設計や命名に関してのスキルがあまり無い場合には、多くの時間を掛けなければまともなコードレビューは出来ないでしょうし、逆にスキルがある場合には短い時間でコードレビューを終わらせることができるでしょう。 特に、ドメイン知識に関してはプロジェクトに新しく入った人が十分に確認することは難しいです。
こういった理由も、コードレビューのトレードオフのベストプラクティスを話すのを難しくしている理由でしょう。
人によってコードレビューに関する心構えが異なる
明確にコードレビューの目的や役割について議論していない場合、レビュワーによってどの指標を重視するのか、どの程度時間をかけて行うのかがバラバラになります。
例えば僕の場合は「可読性」「保守性」を重視してレビューを行い、「機能性」「セキュリティ」に関しては薄くレビューしてしまうことがあります。これは、「レビュイーが機能性については確認しているだろう」「セキュリティ的なスキルが浅いので他のレビュワーに担当してほしい」という気持ちが出てしまい、「比較的スキルのある可読性や保守性を重点的にレビューしてしまう」ためです。 プロジェクトごとにコードレビューで担保したい部分を明らかにしておくのが理想だとは思いますが、コードレビュー基準などが明確になっていない場合は、無意識でこのような行動をしてしまいます。
また、バグやセキュリティ上の問題が発生するのを恐れて、効果が薄いのに時間を多く掛けてしまうこともあります。日々のコードレビューの中で、「自身のコードレビューが適切なのか」という疑問が湧くことが多々ありますが、これはこういった問題があるためだと思います。
コードレビューの費用対効果を最大化させるためにできそうなこと
レビュイー・レビュワーの責任を明らかにしておく
先述の通り、「比較的得意な部分は重点的に確認し、他が疎かになってしまう」ようなことがある場合には、レビュイー・レビュワーの責任を明らかにしておくと、問題が緩和されそうな気がします。
例えば、「レビュイーが機能的に問題ないことを確認し、レビュワーが可読性や設計についてレビューする」といった形で、責任を明らかにしておくと、それぞれがレビューを通して行わなければならないことがわかりやすくなるでしょう。 コードレビューを通して、レビュイー・レビュワーがそれぞれチェックした部分を明記していけば、漏れているレビュー観点なども都度相談することが出来ます。
コードレビューを通して担保する内容を明らかにしておく
これは一つ前の内容と被るところですが、コードレビューを通してどのような部分を重点的にレビューするかの認識を合わせておくことで、より良いレビューができると思います。 「とりあえず問題がないか見てほしい」という曖昧な依頼だと個々人によってレビューの質に差が出過ぎてしまいますし、「十分なレビューが出来ているだろうか」という精神的な負担になってしまいます。
適切なレビュワーアサインをする
個々人によってスキルが異なる以上、レビューの質を保つためにはレビュワーのアサインを適切にする必要があるでしょう。 例えば、プロジェクトの重要な処理を変更する場合に、プロジェクト経験の浅い人だけをアサインするのは危険です。プロジェクト全体の設計やドメイン知識などは、一朝一夕で身につくものではないので、個々人のスキルをある程度把握した上で、適切なアサインをすることで、コードレビューの質を担保することが出来ます。
コードレビューに必要なスキルを明確にする
前述の通り、コードレビューには非常に多くの指標があり、時間をかけてチーム全体でそのスキルを身につけていき、「チームとして適切なレビューができるようになる」必要があります。 全員が全体的にスキルを身につけていく方法もあれば、「Aさんは設計が得意だから設計に関するレビューを行い、知識を共有する」「Bさんはセキュリティが得意だからセキュリティ上の問題が発生する可能性がある場合にはレビューを行い、知識を共有する」といった方法もあるでしょう。
まとめ
- コードレビューは難しい
- コードレビューにかける時間と効果のトレードオフが存在する。そのトレードオフの最適解は(恐らく)人・チーム・プロジェクトによって変わる
- チームやプロジェクトごとにコードレビューの目的・役割分担を議論して明確化しておくことでより良いコードレビューができる(はず)
コードレビューは非常に多くのエンジニアが経験することですが、多くの人が行う作業にしてはかなり難しく、暗黙知になっている部分が多いと感じています。コードレビューに悩んでる人達から話を聞いて、自身の状況にあった解決方法を探していきたいですね。
コメント大歓迎です。是非お話聞かせてください
