よくあるコードレビューのタイミング
コーディング → 初動作確認 → 単体試験 → 結合試験 → (コードレビュー)
結合試験後にコードレビューすることが多い印象です。 品質が担保された状態でレビューできるので、安心感があります。
結合試験後のレビューの落とし穴
- 修正が入ると単体試験からやり直しになるので、指摘しづらい／指摘されたくない空気が生まれる
- 「動いているから大丈夫だろう」と、本質的な問題が見逃されがち
結果として、レビューがおざなりになりやすい、 形だけのレビューになってしまう危険性があります。
他のタイミングだとどうなる？
単体試験前
- レビュアーからすると、動かないコードを見せられても困るし、 ロジックのミスも試験で事前に潰せたはず…とモヤモヤします。
結合試験前
- レビュイー目線だと、修正で単体試験コードも作り直しになるのが辛い。 (単体試験コードはモック化やカバレッジ網羅など結構時間かかることが多い印象)
結合試験後にレビューするのが品質保証の面ではベストだと思えます。 ただし、手戻りが大きくなりがちなのが課題です。
そこで、以下のような案があります。
案1：プロセス短縮化
- 単体試験や結合試験を自動化して、レビュー後の修正もサクッと対応できるようにする。 (AIによる試験コード作成、CI/CDなどによるテスト自動実施)
案2：AIによるレビュー
- 人間ではなくAIでレビューするなら、タイミングはコーディング終わり(またはコミット単位などコーディング中)が良さそう。 早い段階で品質チェックできるので、手戻りも減ります。
まとめ
結合試験後のレビューは品質保証の観点で最適。 ただし手戻りを減らすためにはプロセスの短縮化やAI活用も有効です。 現場や目的に合わせて、最適なタイミングを選びましょう！
