大規模なチームでは、すべてのPRが少なくとも1人の他のエンジニアによってレビューされます。Sage Ideasでは、私が唯一のエンジニアです。誰も私のコードをレビューしません。
これは問題です。私が悪いコードを書くからではありません。自分の前提に気づけないからです。すべての開発者がそうなのです。
私は、二人目の目が捉えるであろうもののほとんどをキャッチする自己レビュープロセスを開発しました。完璧ではありませんが、「よさそう、マージ」よりは格段に優れています。
24時間ルール
今日書いたコードは決してレビューしません。書いてからレビューするまでの最低間隔は24時間です。理想的には48時間です。
これは遅く聞こえますが、実際は速いです。その24時間の間に、私は別のものを構築しています。レビューに戻ってきたときには、実装を部分的に忘れています。その「忘れること」がポイントです。それによって、他の誰かが書いたコードのように読めるのです。
レビューチェックリスト
私は4つのパスでレビューします。各パスで異なるものをチェックします：
パス1：ユーザーとして読む（5分）
コードを見ないでください。PRの差分を開き、ファイル名と行数だけを読んでください。
質問：
- ファイル名だけで変更内容が理解できますか？
- 触っているファイルが多すぎませんか？（結合度の高い変更の兆候）
- この変更に含まれるべきでないファイルはありませんか？
パス2：ロジックを読む（15分）
次にコードを読みます。ただし、スタイル、命名、フォーマットはチェックしません。ロジックだけです。
質問：
- ハッピーパスは機能しますか？
- null/undefinedの入力ではどうなりますか？
- 静かに失敗するケースはありませんか？
- エラーケースを処理していますか、それともログを出力して先に進んでいるだけですか？
- レースコンディションはありませんか？（特に非同期コードで）
パス3：セキュリティを読む（10分）
\\
