コードレビューガイドライン
考えていたのだが、いまいち信憑性が低い話ばかりでどうしたものかと悩んでいる。 このブログは匿名性ではないので怪文書ではないのだが、怪文書に近い出来だ。 もっと納得出来る理由を添えたいのだが、さあ、どうしようか…
コードレビューの基本的方針
コードレビューの目的は下記の通り。
- 設計や実装をレビュワーと共有すること
- バグの温床を見つけること
コードを綺麗にすることではないので注意が必要です。
綺麗の捉え方は主観なので、時として不毛なコミュニケーションに発展します… 「コードが綺麗！」という価値観はコードレビュー時は捨てましょう。 （褒めるための「コードが綺麗！」はどんどん言いましょう、言っているとどういうコードが綺麗なのかという認識が周囲に認知され始めます）
コードレビューでやらないこと
- Linterが指摘出来るような指摘
- 機械が出来ることを人間がやるのは時間の無駄です、Linterがなければすぐに導入しましょう。
- ショートハンドコーディングを勧める
- 些細なパフォーマンスの話
- 結果に特に影響を与えない些細なパフォーマンスの話は無駄です（結果が同じなので）。
- コストが
O(n)になる実装などで、実装当初は0<n<10とかだったけれど未来はどうなるの？という話はしっかりしましょう、これは些細なパフォーマンスの話ではありません。
コードレビューを円滑に進めるためにやっておきたいこと
コミュニケーションが同期的であると、当事者間の共有は万全ですがコミュニケーションに参加しない人に対する共有が不完全になりがちです。 非同期コミュニケーションであるドキュメントを書くことを強く推奨します。 （同期コミュニケーションは常に１：Nの関係（数字は人数）になりますが、ドキュメントによる非同期コミュニケーションは０：Nで説明が成立するケースがありコスト的なメリットがあります。）
設計の共有
機能の規模によっては設計の共有はレビュー前には不可欠です。 これを共有することで、コードが設計とリンクするのでレビューの負担が大きく減少します。
設計の共有方法は機能の大きさによって異なります。
そもそもプロジェクトに設計方針が無いのだけど！？
過去の遺産を引き継ぐ場合、よくあります。 以下の行動を取りましょう。
- 前任者がいるならとにかくしつこく聞く
- 読み取れる範囲で設計方針をドキュメントにする
- 改善したほうが良さそうな方針があれば改善した方針でドキュメントにする
プロジェクトに対する人のアサインが流動することを前提とすると、基本方針の説明をドキュメントに任せられることは大きなコスト削減となります。 （そして基本方針は時間に対してそこまで大きく変更されることがありません。） 可能な限りやっておきましょう。
大きな機能
- レビュー依頼画面に書く情報としては大きくなりすぎるので、専用のドキュメントツールを利用します。
- 実装に入る前にDraftとして設計情報のレビューを行うのが良いです。
- UMLやワイヤフレームをドキュメントに添えて情報を伝えやすくします。
中ぐらいの機能／修正
- 実装する機能は専用のドキュメントツールに記載された機能の一部なら、それへのリンクを記します。
- 修正である場合、専用のドキュメントツールに記載された機能の一部ならドキュメントを修正します。
- 何故その変更や追加が必要だったのかを記載します。
小さい機能／修正
- 何故その変更や追加が必要だったのかを記載します。
