🐡
コードレビューの目的
Why: コードレビューの目的
コードの変更動機を理解して修正できる人(メンテナー)を増やすことで開発生産性を維持すること
- ビジネス要求は変化する
- 顧客の求める機能を探索するために反復的な試行錯誤が必要
- そもそも顧客の要求が市場環境により変化する
- ビジネス要求の変化に素早く対応できるソフトウェアにすることは企業の利益に直結する
- アジャイル(俊敏) = 変更容易性が高い状態にする
- 「ソフトウェアエンジニアリングは時間で積分したプログラミングである」
- 変更可能なソフトウェアを維持するためにコードレビューする
- 他のチームメンバーが理解できるコードになっているか
- 未来の自分が理解できるコードになっているか
What: コードレビューとは何か
「他者(未来の自分も含む)にとって、そのコードがメンテナンスできる状態であるかどうか」をメンバー間で合意形成する場
- コードの変更動機：コードがなんのために書かれているか理解できることの確認
- 例：ユーザー名のよる検索機能を作るため、アカウント作成時にユーザー名をユニークにしたい
- コード変更はわかるが、なぜその仕様が必要なのかわからないと意図しないバグが起きたりする
- 仕様を満たすために最小限のコード変更になっているか
- コードの変更内容：コードが何をしているか理解できることの確認
- 例：アカウント作成する時にユーザー名がユニークなるバリデーションをかけている
- パッと読んで処理内容がわかる状態であること
- 変数名がわかりやすい
- 条件分岐が少ない
- コードの設計：コードを拡張することができることの確認
- 例：バリデーションにユーザー名の文字数制限も追加したい
- 設計が疎結合になっているか
コードレビューの主目的ではないが副次効果として期待できること
- バグの発見
- テストやQAでやるべきこと
- コードレビューの工数を増やしてもバグの見落としは起こりうる(人力なので)
- 技術的な知識の共有
How: どんなやり方が好ましいか
レビュイー(プルリク出す人)に求められること
以下3点を自問自答しておくと良さそう
- コードの変更動機がレビュワーに理解できるか？
- レビュワーはどこまでコンテキストを把握しているか知るところから
- 過去に周辺コードを触っていそうか
- 要求仕様が必要となったビジネス背景を知っていそうか
- コンテキストが異なる人には手厚めにプルリクのdescriptionを書く
- レビュワーはどこまでコンテキストを把握しているか知るところから
- コードの変更内容がレビュワーに理解できるか？
- 変更動機を達成するために、なぜこのコード変更が必要なのか、理由を説明する
- 他に比較検討した方法があれば共有する
- コードの修正がレビュワーに可能であるか？
- 拡張可能な設計を維持できているか
レビュワー(レビューする人)に求められること
- 指摘の優先度を明記する
- 優しい言葉遣い
参考資料
Discussion