『Googleのソフトウェアエンジニアリング』

https://images-na.ssl-images-amazon.com/images/I/61Gx3rNo4LL.jpg

目次

監訳者まえがき

序文

はじめに

第1部　主題

1章　ソフトウェアエンジニアリングとは何か

1.1　時間と変化

1.2　スケールと効率

1.3　トレードオフとコスト

1.4　ソフトウェアエンジニアリング対プログラミング

1.5　結論

1.6　要約

第2部　文化

2章　チームでうまく仕事をするには

2.1　自分のコードを隠すのを手伝ってはくれないか

2.2　天才神話

2.3　隠蔽は有害とみなされる

2.4　チームが全て

2.5　結論

2.6　要約

3章　知識共有

3.1　学びを阻む課題

3.2　哲学

3.3　舞台を整える：心理的安全性

3.4　自分の知識を発展させる

3.5　質問をスケールさせる：コミュニティへの質問

3.6　自分の知識をスケールさせる：教えられるものは常にある

3.7　組織の知識をスケールさせる

3.8　リーダビリティ：コードレビューを通じての標準化されたメンター制度

3.9　結論

3.10　要約

4章　公正のためのエンジニアリング

4.1　バイアスこそがデフォルト状態である

4.2　ダイバーシティの必要性を理解する

4.3　多文化理解の能力を育む

4.4　多様性を行動可能なものにする

4.5　一本槍のアプローチは退けよ

4.6　確立されたプロセスを疑え

4.7　「価値観」対「結果」

4.8　好奇心を持って突き進め

4.9　結論

4.10　要約

5章　チームリーダー入門

5.1　マネージャーとテックリード（とその両方）

5.2　IC役職からリーダーシップ役職への異動

5.3　エンジニアリングマネージャー

5.4　アンチパターン

5.5　建設的パターン

5.6　予期しない質問

5.7　他のヒントや秘訣

5.8　人は植物のようなものである

5.9　結論

5.10　要約

6章　スケールするリーダー

6.1　いつでも決定せよ

6.2　いつでも立ち去れ

6.3　いつでもスケールせよ

6.4　結論

6.5　要約

7章　エンジニアリング生産性の計測

7.1　何故エンジニアリング生産性を計測すべきなのか

7.2　トリアージ：そもそも計測するほどの価値があるか

7.3　ゴールとシグナルを伴う、意味のあるメトリクスを選ぶ

7.4　ゴール

7.5　シグナル

7.6　メトリクス

7.7　メトリクスの検証にデータを用いる

7.8　行動に出ることと結果の追跡

7.9　結論

7.10　要約

第3部　プロセス

8章　スタイルガイドとルール

8.1　何故ルールを設けるのか

8.2　ルールを作る

8.3　ルールを変更する

8.4　ガイダンス

8.5　ルールを適用する

8.6　結論

8.7　要約

9章　コードレビュー

9.1　コードレビューのフロー

9.2　Googleでのコードレビューはどのように機能しているか

9.3　コードレビューの恩恵

9.4　コードレビューのベストプラクティス

9.5　コードレビューの類型

9.6　結論

9.7　要約

10章　ドキュメンテーション

10.1　何がドキュメンテーションとして適格か

10.2　何故ドキュメンテーションが必要なのか

10.3　ドキュメンテーションはコードのようなものである

10.4　対象読者を認識せよ

10.5　ドキュメンテーションの類型

10.6　ドキュメンテーションのレビュー

10.7　ドキュメンテーション哲学

10.8　テクニカルライターが必要なのはどんなときか

10.9　結論

10.10　要約

11章　テスト概観

11.1　何故テストを書くのか

11.2　テストスイートを設計する

11.3　Google規模でのテスト

11.4　Googleでのテストの歴史

11.5　自動テストの限界

11.6　結論

11.7　要約

12章　ユニットテスト

12.1　保守性の重要さ

12.2　脆いテストを防ぐ

12.3　明確なテストを書く

12.4　テストとコード共有：DRYではなくDAMP

12.5　結論

12.6　要約

13章　テストダブル

13.1　テストダブルの、ソフトウェア開発への影響

13.2　Googleでのテストダブル

13.3　基本概念

13.4　テストダブル利用のためのテクニック

13.5　本物の実装

13.6　フェイキング

13.7　スタビング

13.8　インタラクションテスト

13.9　結論

13.10　要約

14章　大規模テスト

14.1　大規模テストとは何か

14.2　Googleの大規模テスト

14.3　大テストの構造

14.4　大規模テストの類型

14.5　大テストと開発者ワークフロー

14.6　結論

14.7　要約

15章　廃止

15.1　何故廃止するのか

15.2　何故廃止はこれほど難しいのか

15.3　廃止の類型

15.4　廃止プロセスを管理する

15.5　結論

15.6　要約

第4部　ツール

16章　バージョンコントロールとブランチ管理

16.1　バージョンコントロールとは何か

16.2　ブランチ管理

16.3　Googleでのバージョンコントロール

16.4　モノリポ

16.5　バージョンコントロールの未来

16.6　結論

16.7　要約

17章　Code Search

17.1　Code SearchのUI

17.2　グーグラーはどのようにCode Searchを使うか

17.3　何故独立したウェブツールなのか

17.4　設計上でのスケールの影響

17.5　Googleの実装

17.6　選択されたトレードオフ

17.7　結論

17.8　要約

18章　ビルドシステムとビルド哲学

18.1　ビルドシステムの目的

18.2　ビルドシステムがないと何が起こるか

18.3　現代的ビルドシステム

18.4　モジュールと依存関係を扱う

18.5　結論

18.6　要約

19章　GoogleのコードレビューツールCritique

19.1　コードレビュー用ツール環境の原則

19.2　コードレビューのフロー

19.3　第1段階：コード変更を作成する

19.4　第2段階：レビューをリクエストする

19.5　第3段階と第4段階：コード変更の理解と、コード変更へのコメント付加

19.6　第5段階：コード変更の承認（コード変更のスコア付け）

19.7　第6段階：コード変更のコミット

19.8　結論

19.9　要約

20章　静的解析

20.1　効果的な静的解析の特徴

20.2　静的解析を機能させる際に鍵となる教訓

20.3　Tricorder：Googleの静的解析プラットフォーム

20.4　結論

20.5　要約

21章　依存関係管理

21.1　何故依存関係管理がそれほど難しいのか

21.2　依存関係のインポート

21.3　理論上の依存関係管理

21.4　SemVerの制限

21.5　無限のリソースがある場合の依存関係管理

21.6　結論

21.7　要約

22章　大規模変更

22.1　大規模変更とは何か

22.2　誰がLSCを扱うのか

22.3　アトミックなコード変更への障壁

22.4　LSCインフラストラクチャー

22.5　LSCプロセス

22.6　結論

22.7　要約

23章　継続的インテグレーション

23.1　CIの概念

23.2　GoogleにおけるCI

23.3　結論

23.4　要約

24章　継続的デリバリー

24.1　Googleでの継続的デリバリーのイディオム

24.2　速度はチームスポーツである：デプロイを管理可能な部分へ分割する方法

24.3　変更を分離して評価する：フラグによる機能の保護

24.4　アジャイル性を目指す：リリーストレインの構成

24.5　品質とユーザー重視：使われるものだけをリリースせよ

24.6　左への移動：データ駆動の決定を早期に行う

24.7　チームの文化を変える：デプロイに規律を組み込む

24.8　結論

24.9　要約

25章　サービスとしてのコンピュート

25.1　コンピュート環境を手なずける

25.2　マネージドコンピュート用ソフトウェアを書く

25.3　長期的にスケールするCaaS

25.4　コンピュートサービスを選択する

25.5　結論

25.6　要約

第5部　結論

あとがき

訳者あとがき

索引

執筆担当者