book

Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス

by Titus Winters, Tom Manshreck, Hyrum Wright, 竹辺靖昭, 久富木隆一

November 2021

Intermediate to advanced

684 pages

10h 37m

Japanese

O'Reilly Japan, Inc.

Read now

Unlock full access

　　1.1　時間と変化　　　1.1.1　Hyrumの法則　　　1.1.2　例：ハッシュの順序付け　　　1.1.3　「何も変化しない」状態をとにかく目指すのはどうか　　1.2　スケールと効率　　　1.2.1　スケールしないポリシー　　　1.2.2　よくスケールするポリシー　　　1.2.3　例：コンパイラーのアップグレード　　　1.2.4　左への移動　　1.3　トレードオフとコスト　　　1.3.1　例：ホワイトボードマーカー　　　1.3.2　意思決定への入力　　　1.3.3　例：分散ビルド　　　1.3.4　例：時間とスケールの間での決定　　　1.3.5　決定を再考すること、間違うこと　　1.4　ソフトウェアエンジニアリング対プログラミング　　1.5　結論　　1.6　要約
　　2.1　自分のコードを隠すのを手伝ってはくれないか　　2.2　天才神話　　2.3　隠蔽は有害とみなされる　　　2.3.1　早期発見　　　2.3.2　バス係数　　　2.3.3　進捗ペース　　　2.3.4　要するに、隠れるな　　2.4　チームが全て　　　2.4.1　社会交流の三本柱　　　2.4.2　何故三本柱に意味があるのか　　　2.4.3　謙虚、尊敬、信頼の実践　　　2.4.4　非難なきポストモーテム文化　　　2.4.5　Google的であること　　2.5　結論　　2.6　要約
　　3.1　学びを阻む課題　　3.2　哲学　　3.3　舞台を整える：心理的安全性　　　3.3.1　メンター制度　　　3.3.2　大規模集団での心理的安全性　　3.4　自分の知識を発展させる　　　3.4.1　質問を尋ねよ　　　3.4.2　文脈を理解せよ　　3.5　質問をスケールさせる：コミュニティへの質問　　　3.5.1　グループチャット　　　3.5.2　メーリングリスト　　　3.5.3　YAQS：Q&Aプラットフォーム　　3.6　自分の知識をスケールさせる：教えられるものは常にある　　　3.6.1　オフィスアワー　　　3.6.2　テックトークと講習　　　3.6.3　ドキュメンテーション　　　3.6.4　コード　　3.7　組織の知識をスケールさせる　　　3.7.1　知識共有の文化を養う　　　3.7.2　カノニカルな情報源の確立　　　3.7.3　情報の輪に参加し続ける　　3.8　リーダビリティ：コードレビューを通じての標準化されたメンター制度　　　3.8.1　リーダビリティプロセスとは何か　　　3.8.2　何故このプロセスがあるのか　　3.9　結論　　3.10　要約
　　4.1　バイアスこそがデフォルト状態である　　4.2　ダイバーシティの必要性を理解する　　4.3　多文化理解の能力を育む　　4.4　多様性を行動可能なものにする　　4.5　一本槍のアプローチは退けよ　　4.6　確立されたプロセスを疑え　　4.7　「価値観」対「結果」　　4.8　好奇心を持って突き進め　　4.9　結論　　4.10　要約

　　5.1　マネージャーとテックリード（とその両方）　　　5.1.1　エンジニアリングマネージャー　　　5.1.2　テックリード（TL）　　　5.1.3　テックリードマネージャー（TLM）　　5.2　IC役職からリーダーシップ役職への異動　　　5.2.1　恐れるべき唯一のものは……えっと、全てだ　　　5.2.2　サーバントリーダーシップ　　5.3　エンジニアリングマネージャー　　　5.3.1　マネージャーとは四文字単語である　　　5.3.2　今日のエンジニアリングマネージャー　　5.4　アンチパターン　　　5.4.1　アンチパターン：押しに弱い者を採用する　　　5.4.2　アンチパターン：成績の悪い者を無視する　　　5.4.3　アンチパターン：人間的問題を無視する　　　5.4.4　アンチパターン：全員の友人になる　　　5.4.5　アンチパターン：採用基準で妥協する　　　5.4.6　アンチパターン：自分のチームを子供のように扱う　　5.5　建設的パターン　　　5.5.1　エゴを捨てよ　　　5.5.2　禅の老師となれ　　　5.5.3　触媒となれ　　　5.5.4　障害を取り除け　　　5.5.5　先生かつメンターになれ　　　5.5.6　明確なゴールを設定せよ　　　5.5.7　正直であれ　　　5.5.8　満足度を追跡調査せよ　　5.6　予期しない質問　　5.7　他のヒントや秘訣　　5.8　人は植物のようなものである　　　5.8.1　「内発的動機付け」対「外発的動機付け」　　5.9　結論　　5.10　要約
　　6.1　いつでも決定せよ　　　6.1.1　飛行機の比喩　　　6.1.2　目隠しを特定せよ　　　6.1.3　鍵となるトレードオフを特定せよ　　　6.1.4　決定し、それから反復せよ　　6.2　いつでも立ち去れ　　　6.2.1　あなたのミッション：「自動運転」チームを構築せよ　　　6.2.2　問題空間の分割　　6.3　いつでもスケールせよ　　　6.3.1　成功の周期　　　6.3.2　「重要」対「緊急」　　　6.3.3　ボールを落とすことを学べ　　　6.3.4　自分のエネルギーを保護する　　6.4　結論　　6.5　要約
　　7.1　何故エンジニアリング生産性を計測すべきなのか　　7.2　トリアージ：そもそも計測するほどの価値があるか　　7.3　ゴールとシグナルを伴う、意味のあるメトリクスを選ぶ　　7.4　ゴール　　7.5　シグナル　　7.6　メトリクス　　7.7　メトリクスの検証にデータを用いる　　7.8　行動に出ることと結果の追跡　　7.9　結論　　7.10　要約
　　8.1　何故ルールを設けるのか　　8.2　ルールを作る　　　8.2.1　指導原則　　　8.2.2　スタイルガイド　　8.3　ルールを変更する　　　8.3.1　プロセス　　　8.3.2　スタイル調停者　　　8.3.3　例外　　8.4　ガイダンス　　8.5　ルールを適用する　　　8.5.1　エラーチェッカー　　　8.5.2　コードフォーマッター　　8.6　結論　　8.7　要約
　　9.1　コードレビューのフロー　　9.2　Googleでのコードレビューはどのように機能しているか　　9.3　コードレビューの恩恵　　　9.3.1　コードの正しさ　　　9.3.2　コードの意味の把握　　　9.3.3　コードの一貫性　　　9.3.4　心理的ならびに文化的な恩恵　　　9.3.5　知識共有　　9.4　コードレビューのベストプラクティス　　　9.4.1　礼儀正しく、かつプロフェッショナルになれ　　　9.4.2　小さな変更を書け　　　9.4.3　良い変更説明を書け　　　9.4.4　レビュアーの人数は最小限にとどめよ　　　9.4.5　可能な場合は自動化せよ　　9.5　コードレビューの類型　　　9.5.1　グリーンフィールドコードレビュー　　　9.5.2　挙動の変更、改善、最適化　　　9.5.3　バグ修正とロールバック　　　9.5.4　リファクタリングと大規模変更　　9.6　結論　　9.7　要約
　　10.1　何がドキュメンテーションとして適格か　　10.2　何故ドキュメンテーションが必要なのか　　10.3　ドキュメンテーションはコードのようなものである　　10.4　対象読者を認識せよ　　　10.4.1　対象読者の類型　　10.5　ドキュメンテーションの類型　　　10.5.1　リファレンスドキュメンテーション　　　10.5.2　デザインドック　　　10.5.3　チュートリアル　　　10.5.4　概念的ドキュメンテーション　　　10.5.5　ランディングページ　　10.6　ドキュメンテーションのレビュー　　10.7　ドキュメンテーション哲学　　　10.7.1　誰が、何を、いつ、どこで、何故　　　10.7.2　始まり、中盤、終わり　　　10.7.3　優れたドキュメンテーションの特徴的要素　　　10.7.4　ドキュメントを廃止する　　10.8　テクニカルライターが必要なのはどんなときか　　10.9　結論　　10.10　要約
　　11.1　何故テストを書くのか　　　11.1.1　Googleウェブサーバーの物語　　　11.1.2　現代的開発速度でのテスト　　　11.1.3　書き、実行し、反応する　　　11.1.4　コードをテストする利点　　11.2　テストスイートを設計する　　　11.2.1　テスト規模　　　11.2.2　テスト範囲　　　11.2.3　Beyoncéルール　　　11.2.4　コードカバレッジについてのメモ　　11.3　Google規模でのテスト　　　11.3.1　大規模テストスイートの落とし穴　　11.4　Googleでのテストの歴史　　　11.4.1　オリエンテーション講習　　　11.4.2　テスト認定プログラム　　　11.4.3　トイレでのテスト　　　11.4.4　今日のテスト文化　　11.5　自動テストの限界　　11.6　結論　　11.7　要約
　　12.1　保守性の重要さ　　12.2　脆いテストを防ぐ　　　12.2.1　変化しないテストを目指す　　　12.2.2　公開API経由のテスト　　　12.2.3　相互作用ではなく、状態をテストせよ　　12.3　明確なテストを書く　　　12.3.1　テストは完全かつ簡潔にせよ　　　12.3.2　メソッドではなく、挙動をテストせよ　　　12.3.3　テストにロジックを入れるな　　　12.3.4　明確な失敗メッセージを書け　　12.4　テストとコード共有：DRYではなくDAMP　　　12.4.1　共有値　　　12.4.2　初期設定の共有　　　12.4.3　ヘルパーメソッドと検証メソッドの共有　　　12.4.4　テストインフラストラクチャーを定義する　　12.5　結論　　12.6　要約
　　13.1　テストダブルの、ソフトウェア開発への影響　　13.2　Googleでのテストダブル　　13.3　基本概念　　　13.3.1　テストダブルの例　　　13.3.2　シーム　　　13.3.3　モッキングフレームワーク　　13.4　テストダブル利用のためのテクニック　　　13.4.1　フェイキング　　　13.4.2　スタビング　　　13.4.3　インタラクションテスト　　13.5　本物の実装　　　13.5.1　分離より現実に即することを優先せよ　　　13.5.2　いつ本物の実装を使うべきか決める方法　　13.6　フェイキング　　　13.6.1　何故フェイクが重要なのか　　　13.6.2　どんな場合にフェイクが書かれるべきか　　　13.6.3　フェイクの忠実性　　　13.6.4　フェイクはテストされるべきである　　　13.6.5　フェイクが利用できない場合はどうすべきか　　13.7　スタビング　　　13.7.1　スタビングを使いすぎることによる危険　　　13.7.2　スタビングが適切なのはどんな場合か　　13.8　インタラクションテスト　　　13.8.1　インタラクションテストよりステートテストを優先せよ　　　13.8.2　インタラクションテストが適切なのはどんな場合か　　　13.8.3　インタラクションテストのベストプラクティス　　13.9　結論　　13.10　要約
　　14.1　大規模テストとは何か　　　14.1.1　忠実性　　　14.1.2　ユニットテストでよくある不足部分　　　14.1.3　何故大規模テストを備えないのか　　14.2　Googleの大規模テスト　　　14.2.1　大規模テストと時間　　　14.2.2　Googleスケールでの大規模テスト　　14.3　大テストの構造　　　14.3.1　テスト対象システム　　　14.3.2　テストデータ　　　14.3.3　検証　　14.4　大規模テストの類型　　　14.4.1　相互に作用し合う1つ以上のバイナリの機能テスト　　　14.4.2　ブラウザーとデバイスのテスト　　　14.4.3　パフォーマンス、負荷、ストレスのテスト　　　14.4.4　デプロイ設定のテスト　　　14.4.5　探索的テスト　　　14.4.6　A/B差分リグレッションテスト　　　14.4.7　ユーザー受け入れテスト（UAT）　　　14.4.8　プローバーとカナリア分析　　　14.4.9　障害復旧とカオスエンジニアリング　　　14.4.10　ユーザー評価　　14.5　大テストと開発者ワークフロー　　　14.5.1　大テストの作成　　　14.5.2　大テストの実行　　　14.5.3　大規模テストのオーナーとなる　　14.6　結論　　14.7　要約
　　15.1　何故廃止するのか　　15.2　何故廃止はこれほど難しいのか　　　15.2.1　設計中の廃止　　15.3　廃止の類型　　　15.3.1　勧告的廃止　　　15.3.2　強制的廃止　　　15.3.3　廃止の警告　　15.4　廃止プロセスを管理する　　　15.4.1　プロセスのオーナー　　　15.4.2　マイルストーン　　　15.4.3　廃止ツール環境　　15.5　結論　　15.6　要約
　　16.1　バージョンコントロールとは何か　　　16.1.1　何故バージョンコントロールが重要なのか　　　16.1.2　「中央集権的VCS」対「分散VCS」　　　16.1.3　信頼できる情報源　　　16.1.4　「バージョンコントロール」対「依存関係管理」　　16.2　ブランチ管理　　　16.2.1　進行中の作業はブランチに似ている　　　16.2.2　開発ブランチ　　　16.2.3　リリースブランチ　　16.3　Googleでのバージョンコントロール　　　16.3.1　単一バージョン　　　16.3.2　シナリオ：複数の利用可能バージョン　　　16.3.3　「単一バージョン」ルール　　　16.3.4　存続期間の長いブランチを（ほとんど）なくす　　　16.3.5　リリースブランチについてはどうか　　16.4　モノリポ　　16.5　バージョンコントロールの未来　　16.6　結論　　16.7　要約
　　17.1　Code SearchのUI　　17.2　グーグラーはどのようにCode Searchを使うか　　　17.2.1　どこに　　　17.2.2　何を　　　17.2.3　どのように　　　17.2.4　何故　　　17.2.5　誰が、いつ　　17.3　何故独立したウェブツールなのか　　　17.3.1　スケール　　　17.3.2　設定作業不要のグローバルコードビュー　　　17.3.3　専門化　　　17.3.4　他の開発者ツールとの統合　　　17.3.5　API公開　　17.4　設計上でのスケールの影響　　　17.4.1　検索クエリーのレイテンシー　　　17.4.2　インデックスのレイテンシー　　17.5　Googleの実装　　　17.5.1　検索インデックス　　　17.5.2　ランキング　　17.6　選択されたトレードオフ　　　17.6.1　完全性：ヘッドにあるリポジトリー　　　17.6.2　完全性：「全部」対「最も関連性の高い結果」　　　17.6.3　完全性：「ヘッド」対「ブランチ」対「全履歴」対「ワークスペース」　　　17.6.4　表現力：「トークン」対「部分文字列」対「正規表現」　　17.7　結論　　17.8　要約
　　18.1　ビルドシステムの目的　　18.2　ビルドシステムがないと何が起こるか　　　18.2.1　でも必要なのはコンパイラーだけ！　　　18.2.2　シェルスクリプトは救援となるか　　18.3　現代的ビルドシステム　　　18.3.1　依存関係こそ全て　　　18.3.2　タスクベースのビルドシステム　　　18.3.3　アーティファクトベースのビルドシステム　　　18.3.4　分散ビルド　　　18.3.5　時間、スケール、トレードオフ　　18.4　モジュールと依存関係を扱う　　　18.4.1　粒度の細かいモジュールの利用と1:1:1ルール　　　18.4.2　モジュールの可視性の最小化　　　18.4.3　依存関係の管理　　18.5　結論　　18.6　要約
　　19.1　コードレビュー用ツール環境の原則　　19.2　コードレビューのフロー　　　19.2.1　通知　　19.3　第1段階：コード変更を作成する　　　19.3.1　差分作成　　　19.3.2　解析結果　　　19.3.3　緊密なツール統合　　19.4　第2段階：レビューをリクエストする　　19.5　第3段階と第4段階：コード変更の理解と、コード変更へのコメント付加　　　19.5.1　コメント付加　　　19.5.2　コード変更の状態を理解する　　19.6　第5段階：コード変更の承認（コード変更のスコア付け）　　19.7　第6段階：コード変更のコミット　　　19.7.1　コミット後：履歴の追跡　　19.8　結論　　19.9　要約
　　20.1　効果的な静的解析の特徴　　　20.1.1　スケーラビリティ　　　20.1.2　ユーザビリティ　　20.2　静的解析を機能させる際に鍵となる教訓　　　20.2.1　開発者の幸福を重視せよ　　　20.2.2　静的解析を中心的な開発者ワークフローの一部とせよ　　　20.2.3　コントリビュートする権限をユーザーに与えよ　　20.3　Tricorder：Googleの静的解析プラットフォーム　　　20.3.1　統合されているツール　　　20.3.2　統合されているフィードバック経路　　　20.3.3　修正提案　　　20.3.4　プロジェクトごとのカスタマイズ機能　　　20.3.5　リポジトリー提出前処理　　　20.3.6　コンパイラー統合　　　20.3.7　コードの編集中と閲覧中の静的解析　　20.4　結論　　20.5　要約
　　21.1　何故依存関係管理がそれほど難しいのか　　　21.1.1　競合する要件群とダイアモンド依存関係　　21.2　依存関係のインポート　　　21.2.1　互換性の約束　　　21.2.2　インポートを行う際に考慮すべき事項　　　21.2.3　Googleはどのように依存関係のインポートを扱っているか　　21.3　理論上の依存関係管理　　　21.3.1　何も変化しない（別名：静的依存関係モデル）　　　21.3.2　セマンティックバージョニング　　　21.3.3　バンドルされたディストリビューションのモデル　　　21.3.4　リブアットヘッド　　21.4　SemVerの制限　　　21.4.1　SemVerは過大に制約を課す可能性がある　　　21.4.2　SemVerは過大に約束をする可能性がある　　　21.4.3　動機　　　21.4.4　最小バージョン選択　　　21.4.5　では、SemVerは機能するのか　　21.5　無限のリソースがある場合の依存関係管理　　　21.5.1　依存関係のエクスポート　　21.6　結論　　21.7　要約
　　22.1　大規模変更とは何か　　22.2　誰がLSCを扱うのか　　22.3　アトミックなコード変更への障壁　　　22.3.1　技術的制約　　　22.3.2　マージ競合　　　22.3.3　幽霊の出る墓場をなくす　　　22.3.4　異種多様性　　　22.3.5　テスト　　　22.3.6　コードレビュー　　22.4　LSCインフラストラクチャー　　　22.4.1　ポリシーと文化　　　22.4.2　コードベースの内部的知識　　　22.4.3　コード変更の管理　　　22.4.4　テスト　　　22.4.5　言語サポート　　22.5　LSCプロセス　　　22.5.1　認可　　　22.5.2　コード変更の作成　　　22.5.3　シャード分割とリポジトリーへのコード提出　　　22.5.4　クリーンアップ　　22.6　結論　　22.7　要約
　　23.1　CIの概念　　　23.1.1　高速なフィードバックループ　　　23.1.2　自動化　　　23.1.3　継続的テスト　　　23.1.4　CIの課題　　　23.1.5　密閉されたテスト　　23.2　GoogleにおけるCI　　　23.2.1　CIケーススタディ：Google Takeout　　　23.2.2　だがCIを行う余裕がない　　23.3　結論　　23.4　要約
　　24.1　Googleでの継続的デリバリーのイディオム　　24.2　速度はチームスポーツである：デプロイを管理可能な部分へ分割する方法　　24.3　変更を分離して評価する：フラグによる機能の保護　　24.4　アジャイル性を目指す：リリーストレインの構成　　　24.4.1　完璧なバイナリなどない　　　24.4.2　リリースの締め切りは守れ　　24.5　品質とユーザー重視：使われるものだけをリリースせよ　　24.6　左への移動：データ駆動の決定を早期に行う　　24.7　チームの文化を変える：デプロイに規律を組み込む　　24.8　結論　　24.9　要約
　　25.1　コンピュート環境を手なずける　　　25.1.1　トイルの自動化　　　25.1.2　コンテナ化とマルチテナンシー　　　25.1.3　まとめ　　25.2　マネージドコンピュート用ソフトウェアを書く　　　25.2.1　障害に備えたアーキテクチャー設計　　　25.2.2　「バッチ」対「提供」　　　25.2.3　状態管理　　　25.2.4　サービスへの接続　　　25.2.5　単発コード　　25.3　長期的にスケールするCaaS　　　25.3.1　抽象化としてのコンテナ　　　25.3.2　1つのサービスは全てを統べる　　　25.3.3　リポジトリーへ提出される設定　　25.4　コンピュートサービスを選択する　　　25.4.1　「中央集権化」対「カスタマイズ」　　　25.4.2　抽象化のレベル：サーバーレス　　　25.4.3　パブリック対プライベート　　25.5　結論　　25.6　要約

Content preview from Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス

22章大規模変更

Hyrum Wright 著

Lisa Carey 編

　しばしの間、読者自身のコードベースについて考えてみてほしい。複数のファイルを一斉に更新対象とするコミット1回で、信頼性のある状態で更新可能なファイルの数は何個だろうか。その数を制限する要因は何か。ファイル数に制限がかかるほど大きな変更のコミットをこれまで試みたことはあるか。緊急の場合に、そのようなコミットを妥当な時間内に行うことは可能だろうか。自分が行ったことのあるコミットで最大のもののサイズは、自分のコードベースの現在のサイズとの比較ではどの程度を占めるか。そのような大きなコード変更はどのようにしてテストするのだろうか。その変更をコミット前にレビューするのにレビュアーは何人要ることになるだろうか。その変更は、実際にコミットされた場合にはロールバックが可能だろうか。以上の質問への答えは、意外なものかもしれない（意外というのは、読者が答えだと思っているものと、読者の組織にとって実際にその答えが結局どういうものになるかの両方だ）。

　社内のコードベースの至るところに影響する広範囲のコード変更を、上述の類のアトミックな大規模変更内で行うという考え方は、Googleではとうの昔に放棄されている。我々が見てきた限りでは、コードベースとその中で作業するエンジニアの数が増大するにつれて、アトミックに行うことが可能な変更の最大サイズは、直感に反して減少する。例えば、コード変更が影響するリポジトリー提出前のチェックとテストを全部実行するのが難しくなり、またリポジトリーへのコード提出の前にコード変更内の全ファイルが最新であるのを保証することすら難しくなるのは言うまでもない。社内のコードベースへ広範な変更を行うことが難しくなってきているため、基盤のインフラストラクチャーを絶えず改善できるようにしたいという一般的志向がGoogleには前提としてある以上、大規模変更が実際には何を行うのかについての新しい解釈法と、そのような解釈法を実装する方法とを開発しなければならなくなっている。 ...