Looks Good To Me－～ みんなのコードレビュー [単行本]

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　言語別静的解析ツール一覧

• 出版社からのコメント

  コードレビュー、最高の教科書

• 内容紹介

  コードレビューに関する実践的なガイドブックです。タイトルの『Looks Good To Me』（略して「LGTM」）は、コードレビューにおいては、文字通りの「よいと思う」という意味よりも、「承認する」を意図して使われています。でも、明確な指針やルールがないまま、「雰囲気で」LGTMしていないでしょうか？
  本書では、「なぜコードレビューを行うのか」から始まり、ワークフローの徹底解説、最初のプロセスの構築と、段階的に解説します。さらに高度な要素として、「チームワーキングドラフト」「自動化」、そして最も大事な「効果的なコメント」について、じっくり説明します。「伝わるコメント」には、言葉遣いや文章のトーンが重要で、それを実現する著者の経験から生まれたメソッドが明かされています。
  加えて、コードレビューで直面しがちな「ジレンマ」への対応も解説します。なぜコードレビューがダメになるのか（と、予防策）、なぜ遅れるのか（と、改善策）、なぜ抜け穴が生まれるのか（と、対応策）、「緊急時対応プレイブック」の作成を解説します。
  そして、ほかのソフトウェア開発プラクティスとコードレビューの関係性を分析するとともに、（現時点における）「コードレビューとAI」についても1つの章を割いています。
  包括的にコードレビュー自体を取り上げたドキュメントはほとんどなく、手探りで進めているチームも多いでしょう。でも大丈夫。これからは本書があります。コードレビューを行う理由から、周囲を巻き込む方法、プロセス・システムの構築、自動化の方法とテンプレート、効果的なコメントの書き方、進行中のトラブルの対応策、AIの活用に至るまで、コードレビューに取り組む前、コードレビューで課題に直面したとき、コードレビューを改善したいと考えたときなど、あらゆる場面で参照して活用できる「最高の教科書」です！
  
  ●目次
  Part1 　コードレビューの基本
  　Chapter 1　コードレビューの重要性
  　Chapter 2　コードレビュー徹底解剖
  　Chapter 3　チームの最初のコードレビュープロセスの構築
  Part2 　高度なコードレビューに必須の要素
  　Chapter 4　チームワーキングアグリーメント
  　Chapter 5　自動化のメリット
  　Chapter 6　効果的なコードレビューコメントの作成
  Part3 　ジレンマへの対処
  　Chapter 7　コードレビューがダメになる理由
  　Chapter 8　コードレビューの遅延を減らす
  　Chapter 9　プロセスの抜け穴を取り除く
  　Chapter 10　緊急時対応プレイブック
  Part4 　 コードレビューとその他の開発プラクティスを組み合わせる
  　Chapter 11　コードレビューとペアプログラミング
  　Chapter 12　コードレビューとモブプログラミング
  　Chapter 13　コードレビューとAI
  
  図書館選書
  コードレビューの「何」と「なぜ」から始まり、ワークフローの研究とプロセスの構築を経て、自動化、チーム合意の共同作成、効果的なコメントの書き方など、優れたコードレビューを行うために必須のスキルを学びます。

• 著者について

  Adrienne Braganza (エイドリアンブラガンザ)
  ● Adrienne Braganza（エイドリアン・ブラガンザ）
  フィリピンのソフトウェアエンジニアで、国際的な講演者、『Coding for Kids: Python』の著者、LinkedIn Learningのインストラクター。10年以上のソフトウェア開発とデベロッパーアドボカシーの経験を持ち、本質的なトピック、特にそれらをうまく行う方法を教えることを常に好んでいる。
  
  高田新山 (タカタシンザン)
  ● 高田 新山（たかた しんざん）
  異業種からソフトウェアエンジニアに転職後、受託開発でのさまざまな案件やベンチャー企業での新規自社サービス開発を経験し、現在はLINEヤフー株式会社で、社内におけるオープンソースの利用管理やオープンソースエコシステムへの貢献を推進するOSPO（Open Source Program Office）のメンバーとして、またLINEメッセージングアプリの開発に携わるiOSエンジニアとして働いている。Java、PHP、C#、JavaScriptなどを用いたフロントエンドやバックエンドの開発経験があり、カンファレンスでの登壇や書籍の執筆、翻訳なども行っている。
  
  増井敏克 (マスイトシカツ)
  ● 増井 敏克 （ますい としかつ）
  増井技術士事務所 代表。技術士（情報工学部門）。1979 年奈良県生まれ。大阪府立大学大学院修了。テクニカルエンジニア（ネットワーク、情報セキュリティ）、その他情報処理技術者試験にも多数合格。また、ビジネス数学検定1 級に合格し、公益財団法人日本数学検定協会認定トレーナーとしても活動。「ビジネス」×「数学」×「IT」を組み合わせ、コンピュータを「正しく」「効率よく」使うためのスキルアップ支援や、各種ソフトウェアの開発を行っている。

Looks Good To Me－～ みんなのコードレビュー の商品スペック