はじめに
GTDツールのNozbeのテンプレートにコードレビュー方法があったので、意訳してみました。コードレビューをし始めたいけど、何をレビューしたら良いのかわからない人は、これに倣ってみてはどうでしょうか。
- How to run a good code review - programming by Stanisław
-
nozbe.how
- nozbeを使っていたら、GTDとして取り込めるテンプレートがいくつも掲載されています。
経緯を読む
機能追加やリファクタリングの経緯を理解すること。
何も取っ掛かりがなければレビュイーに取っ掛かりを書いてもらって下さい。
参照例：
- Githubの Pull Requestなど
- 関連するタスクチケットなど
関連する事柄を読み、質問して下さい。
下記の質問をし、返答をもらって下さい。
- 前提条件は何ですか？
- 最終ゴールは何ですか？
技術的な解釈を読む
他の誰かがコードレビューをした後、その人の指摘が解決しているかどうかを注意深く確認します。
機能を使ってみる（１５分）
ユーザの立場になって１５分間だけ、アプリを操作してみてください。
- 実装された機能は動きましたか？
- 意図したとおりに動いて、正しい結果を得られましたか？
- 軽快に動きましたか（遅いデバイスでも）？
修正や実装について考える
自問する：もし自身が実装するとしたらどのように書くべきだろうか？ 実際のコードを思い出して自身のアイデアと比較してください。誰のアイデアがより良かったですか？もし自身のアイデアが良いと思うのなら修正の提案をして下さい。
コードを読む
修正による影響を見逃していないかコードを確認してください。例えば、テスト時に要確認とするような、難しい実装の箇所など。
コードを自身のローカル環境でコンパイル／実行してみる
ローカル環境にpullし、リモートにpushする前と同じようにテストして下さい。
細かく確認してください
（下記がそぐわないなら、実行環境差異、実行モード差異、オフライン、エラー処理、異常系対応、情報漏洩有無などを確認しましょう）
- 少なくとも２つ以上のブラウザで起動してください
- 必ず実機で起動してください
- プロダクション版と同じようにデベロップメント版を操作して下さい
- オフライン状態で起動してください
- 取得可能なエラーを全て発生させてください
- フォームに異常な値を入れて何が起こるか確認してください
- データ漏洩が起こっていないか確認して下さい
フィードバックしてください
コードを読み進めていく上で、文体、アーキテクチャ、その他の意思決定を恐れないでください。丁寧なフィードバック、質問、解決策の提案を行って下さい。
このように：
- 何故このようにしたのですか？
- ココでソレした理由は何ですか？
- これは２つに分割できなかったんですか？
- これはドキュメント化するべきだと思います
- この部分は分かりにくいです
- より明確な名前は"foo"だと思います
- これを別の関数に抽出するにはどうすべきですか？
- ソレは他の既存のコードより一貫性があると思います
コードをもう一度読む
自問に適した質問事項：
- 全部のコードは読みやすいですか？ いくつかの小さなコードを理解するのに５分以上時間が掛かる場合、コードリーディングを止め、それを書いた人に説明してもらって下さい。コードが小さくないと思ったら、説明しやすいようリファクタリングやコメントの補記を提案してください。
- コーディング規約に則っていますか？ コーディング規約に沿ってコードをテスト出来るようにして下さい。
- コードはリリース可能ですか？ 冗長或いは重複したコードはありませんか？ コメントアウトしたコードはありませんか？ デバッグ記述などは除去できていますか？
- コードはテスト可能ですか？ 複数或いは暗黙の依存関係がなく、テストフレームワークは単独で実行クラスやメソッドにアクセスできること。
- コードはセキュリティ標準に即していますか？ プライバシーを尊重していますか？
総感を書く
気がついた箇所の指摘が終わった後、欠点は改善されている筈です。実装と機能全体の印象を説明します。
- この修正案はどのような改善をするか？
- どのようにその影響を測定するか？
- 想定外の異常系はあるか？
出荷しろ！
Remember: 出荷するまでは実績は無い！
- 待つな
- どのジョブも完了していないことに気付いた場合、フィードバックして下さい。
- マージ テストがパスするか、それ以上問題が見つからなければ実施して下さい。
- 祝え