「コードレビューたまりがち問題」を解決するには

どうしてコードレビューはたまるのか？

  • 問題: コードレビューを後回しにしてしまう
    • 原因: コンテキストスイッチが大変だから
      • 助長する要因
        • PRがデカい
          • 変更行数が数百行あったり、複数のコンテキストが 1 つの PR に混ざっているとか
        • PRの説明を読んでも、レビューしてほしい観点・目的・意図などがよく分からない
          • コードを隅々まで読まないと意図が見えてこないとか
        • PRの内容と、自分が取り組んでいる開発タスクとの関連が浅い
          • とある機能開発をしている最中に規模の大きめのリファクタリングのレビュー依頼をされたとか
    • 対策
      • レビュワー、レビュイー
        • コンテキストの同じタスクにリソースを集中させる
          • 複数人で開発ができる状態になっている必要があります。
        • コード以外のレビューは別でやる
          • 仕様レビューなら仕様書のレビュー、設計レビューなら設計書のレビュー
      • レビュワー
        • コンテキストスイッチが大変ならさっさとそれを伝える
          • 変更行数がデカすぎるので分割してほしいです
          • 色んな修正が混ざっちゃってるので分けてほしいです
          • 説明を読んでもどんな観点でレビューしてほしいのか自分には分からなかったので、教えてほしいです
          • このタスクにはあまり関わってなくて背景知識に乏しいので、もう少し説明をお願いしたいです
      • レビュイー
        • レビュアーに事前に予告する
          • レビューに時間がかかりそうな PR を投げるときは、できるだけ事前に伝えるようにしましょう。
        • レビューしやすい PR を作る
          • [コードレビューを通過するための CL 作成者のガイド google-eng-practices-ja](https://fujiharuka.github.io/google-eng-practices-ja/ja/review/developer/) は必読
  • 問題: レビュアーが特定のメンバーに偏ってしまう
    • 原因: リードエンジニアにレビュー依頼が集中するから
      • 書かれたコードが正しく動作するかを確認する
      • 書かれたコードが設計思想に合っているかを確認する
      • 書かれたコードが他の範囲に悪影響を与えていないかを確認する
    • 対策
      • 第三者の目線が入るだけで意味があると考える
        • 第三者がコードを確認することで、コードを書いた本人が見落としていたことに気づけたりします。
          • これはリードエンジニアが確認しないと達成できないということはなく、チームのメンバーであれば大体誰でも問題ないです。
      • リードエンジニアのレビューが必要な基準を決める
        • レビューしてみて不安なところがでてきたら、そこだけリードエンジニアにレビューをお願い
        • セキュリティなど、いわゆるクリティカルな部分だけは始めからリードエンジニアにレビューしてもらう