日曜なのでポエミーな雑記です。
何故コードレビューをやるのか
大きくは2つある
機能的な仕様を満たせているかのチェック
- そもそもの機能要件を満たしているかのチェック
- 書いたコードが要求仕様に沿ってなければ意味がない。
- 機能要件におけるバグの有無もココらへんがチェック対象
システムの構造やソースコードレベルの品質のチェック
- 非機能要件における問題点の発見
- 機能を満たしていても、それにおいて他の機能を阻害するなどあってはならない
- 機能の要件には含まれないが、提供するシステムとして問題があるものはないか（セキュリティホールや致命的なパフォーマンス低下など）
- 変更および変化に強いコードであるかのチェック
- ことWebアプリケーションにおいては作って終わりではなく、作ったアプリが常に変化し成長していく、そのような条件に耐えられる構造になっているか
- テストコードが含まれるなど、継続的に変化できるだけの下地が整っているか
コードレビューの難しいポイント
『そもそもの機能要件を満たしているかのチェック』において
- レビュアーが仕様をしっかり理解する必要がある
- レビュアーがその機能の隠れたバグをおもんばかることができる必要がる
- レビュアーが仕様を含めたコンテキストを理解して機能に影響がないかを感知できる必要がある
『非機能要件におけるバグの発見』において
- 非機能要件なのでインフラ環境などに依存するバグがないか、アプリケーション全体をとりまくコンテキストを理解する必要がある。
- セキュリティなど機能としては注視されないが、認識を誤ると問題となるようなものもあるので、それを見極める審美眼が必要になる。
『変更および変化に強いコードであるかのチェック』において
- 短絡的に書かれたコードか、先を見据えて書かれたコードかを判断する審美眼が必要。
- 変化に強い、ということを何か言葉をもって説明できる必要がある。
- 利用されているプログラミング言語としておかしな記述を行っていないかを認識する必要がある。
