Looks Good To Me

Part 1　コードレビューの基本
　Chapter 1　コードレビューの重要性
　　1.1　本書の対象読者
　　1.2　本書の構成
　　1.3　コードレビューはなくてはならないもの
　　　1.3.1　より優れたアプリ
　　　1.3.2　チーム全体の理解の向上
　　1.4　チームを説得する
　　1.5　コードレビューを改善する
　　まとめ
　Chapter 2　コードレビュー徹底解剖
　　2.1　コードレビューのシステム
　　　2.1.1　人間主導型
　　　2.1.2　ツール支援型
　　　2.1.3　ハイブリッド型
　　2.2　コードレビューはどのように機能するのか？
　　　2.2.1　現代のコードレビューのワークフロー
　　　2.2.2　PRベースのコードレビュー（PRワークフロー）
　　2.3　優れたPR（またはMR）の要素
　　　2.3.1　タイトル：「何」
　　　2.3.2　説明（「なぜ」）
　　　2.3.3　ラベル
　　　2.3.4　レビューの状態（ステータス）
　　2.4　コードレビューの参加者と期待
　　　2.4.1　レビュー担当者
　　　2.4.2　PR作成者
　　　2.4.3　チーム
　　　2.4.4　責任者
　　　2.4.5　組織
　　まとめ
　Chapter 3　チームの最初のコードレビュープロセスの構築
　　3.1　目標を設定する
　　　3.1.1　バグの発見
　　　3.1.2　コードベースの安定性とメンテナンス性
　　　3.1.3　知識移転・共有
　　　3.1.4　メンタリング
　　　3.1.5　記録の保持・作成
　　　3.1.6　コードレビューの目標の選定
　　3.2　ツールの選定
　　　3.2.1　コードレビュー機能の評価
　　　3.2.2　ツールの選定
　　3.3　ガイドラインを設定する
　　　3.3.1　ワークフローとは？
　　　3.3.2　レビューの焦点は何か？
　　　3.3.3　PRの承認を止めるべきものは何か？
　　　3.3.4　承認ポリシーはどうなっているか？
　　3.4　プロセスの改良
　　　3.4.1改良シナリオのウォークスルー
　　まとめ

Part 2　高度なコードレビューに必須の要素
　Chapter 4　チームワーキングアグリーメント
　　4.1　チームワーキングアグリーメントとは何か？
　　4.2　TWAを使ったチームの期待値の設定
　　　4.2.1　シナリオ1：迅速なレビューとそうではないレビュー
　　　4.2.2　シナリオ2：意見の不一致
　　　4.2.3　シナリオ3：承認するかしないか？
　　4.3　チームで一緒にTWAを確立する
　　　4.3.1　TWAは本当に必要ですか？
　　4.4　TWAに含めるべき項目
　　　4.4.1　さらなる暗黙的なコードレビューの期待
　　　4.4.2　適切な応答時間
　　　4.4.3　適切なPRサイズ
　　　4.4.4　問題の特定
　　　4.4.5　PRの自己承認
　　　4.4.6　ニットピック（Nitpicks）
　　　4.4.7　ポジティブなレビュー環境
　　　4.4.8　ポリシーに違反するとどうなるのか？
　　4.5　このTWAはチームのドキュメントです
　　　4.5.1変更が必要ですか？
　　　4.5.2最後に
　　まとめ
　Chapter 5　自動化のメリット
　　5.1　自動化という資産
　　5.2　自動化の前提条件
　　　5.2.1　チームのスタイルガイド
　　　5.2.2　効果的なツール
　　5.3　レビュー前の自動化
　　　5.3.1　フォーマット
　　　5.3.2　リンティング
　　　5.3.3　静的解析ツール
　　　5.3.4　自動テスト
　　5.4　レビュー中の自動化
　　　5.4.1　PRテンプレート
　　　5.4.2　PRバリデータ
　　　5.4.3　レビュー担当者の割り当て
　　　5.4.4　PRゲートチェック
　　　5.4.5　リマインダーとエスカレーション
　　まとめ
　Chapter 6　効果的なコードレビューコメントの作成
　　6.1　効果的なコメントの特徴とは？
　　　6.1.1　客観性
　　　6.1.2　具体性
　　　6.1.3　明確な結果
　　　6.1.4　効果的なコードレビューコメントの例
　　6.2　トーン
　　6.3　コードへの賞賛
　　まとめ

Part 3　ジレンマへの対処
　Chapter 7　コードレビューがダメになる理由
　　7.1　コードレビューの苦悩
　　　7.1.1　いい加減なコードレビュー
　　　7.1.2　意地悪なコードレビュー
　　　7.1.3　変幻自在なコードレビュー
　　　7.1.4　厳しすぎるコードレビュー
　　7.2では、どうすればよいのか？
　　まとめ
　Chapter 8　コードレビューの遅延を減らす
　　8.1　「PRをレビューするシニア開発者が1人しかいません」
　　8.2　「PRが理解できません」
　　8.3　「レビューするファイルが多すぎます」
　　8.4　「機能が大きすぎてレビューできません」
　　8.5　「議論の応酬が多すぎます」
　　8.6　「コードにリファクタリングが必要（時には何度も）」
　　まとめ
　Chapter 9　プロセスの抜け穴を取り除く
　　9.1　どのように抜け穴が発生するのか？
　　9.2　抜け穴（および、その修正方法）
　　　9.2.1　未定義のコードレビュープロセス
　　　9.2.2　コードレビューの時間不足
　　　9.2.3　ツールの設定ミス
　　　9.2.4　フィードバック文化の欠如
　　　9.2.5　承認主導型の指標
　　　9.2.6　緊急事態の悪用
　　まとめ
　Chapter 10　緊急時対応プレイブック
　　10.1　緊急時対応プレイブックとは？
　　10.2　緊急時対応プレイブックには何を含めるべきか？
　　　10.2.1　意思決定ツリー
　　　10.2.2　承認プロセス
　　　10.2.3　回避メカニズム
　　　10.2.4　次のステップ
　　10.3　緊急時対応プレイブックはいつ使用するのか？
　　まとめ

Part 4　コードレビューとその他の開発プラクティスを組み合わせる
　Chapter 11　コードレビューとペアプログラミング
　　11.1　コードレビューとペアプログラミング、どちらを行うべきか？
　　　11.1.1　ペアプログラミングによるコードレビューの補完
　　　11.1.2　ペアプログラミングはコードレビューに置き換わることはない
　　11.2　ペアプログラミングの導入
　　　11.2.1　ペアプログラミングを試すようにチームを説得する
　　　11.2.2　ペアプログラミングのスタイル
　　　11.2.3　効果的なペアプログラミングのための検討事項
　　まとめ
　Chapter 12　コードレビューとモブプログラミング
　　12.1　コードレビューとモブプログラミング、どちらを行うべきか？
　　　12.1.1　モブプログラミングの強み
　　　12.1.2　モブプログラミングによるコードレビューの補完
　　　12.1.3　モブプログラミングはコードレビューに置き換わることはない
　　12.2　モブプログラミングの導入
　　　12.2.1　補完的なアプローチ
　　　12.2.2　モブプログラミングの課題
　　まとめ
　Chapter 13　コードレビューとAI
　　13.1　コードレビューにおけるAIのメリット
　　　13.1.1　レビューの迅速化
　　　13.1.2　コードの品質向上
　　　13.1.3　レビューの一貫性
　　　13.1.4　大規模チームやコードベースへのレビューの拡張性
　　13.2　コードレビューにおけるAIの限界
　　　13.2.1　コンテキストとドメイン知識の理解の難しさ
　　　13.2.2　機能はトレーニングデータに大きく依存する
　　　13.2.3　AIへの過度な依存は、レビュー担当者の専門性を妨げる可能性がある
　　13.3　AIを活用したコードレビューで何ができるか？
　　13.4　コードレビューへのAIの導入
　　13.5　コードレビューの未来：人間とAIの協働
　まとめ

Appendix　付録
　Appendix A　チームワーキングアグリーメントスターターテンプレート
　Appendix B　緊急時対応プレイブックスターターテンプレート
　　B.1　緊急時手順の名称
　　B.2　意思決定ツリー
　　B.3　承認プロセス
　　B.4　回避メカニズム（および、関連タスク）
　　B.5　次のステップ
　　　B.5.1　文書化
　Appendix C　PRテンプレート集
　Appendix D　リソースリスト
　　D.1　本書で言及した使用したリソースの一覧
　　D.2　言語別リンター一覧
　　D.3　言語別静的解析ツール一覧