アプリ開発にも応用できる話があるかなと思って買ったが、当たり前だけどWebフロントエンドに関する内容だけです。
組織にマイクロフロントエンドを組織に導入する際に、仕組みとして委員会を設置した方が良いとかあるが、この辺りは多少は参考になるかも。
内容的にはフロントエンド的にも、そんなに特別なことは書いてないと思う。テストかけとか分散したチームをまとめるために自動化とそれを維持するインフラに投資すべきとか。
マイクロなんちゃらに限らず、組織が大きくなったらある程度は投資しないとダメなことだとは思う。
エンジニアのためのキャリアパス
と同じ感じで、困った時に見返すと良さそう。
各トピックが短いのですぐに読めるし。
すごい特別なことが書いてあるわけではない。
質問表
日本と中国の関係性を描きながら日本の歴史の概要を追いかけていくような内容になっている。
歴史の本は大抵そうなんだけど、一つ読んだだけだとわからないけど、すでに概要を知っていると面白くなるものもある。これもそんな本。
日本はやはり中国から見ると遅れていて、それは日本も自覚していて、なので中国の真似をするところから国家の形が出来ていく。
そして、温暖化と共に世界的にも中央集権というよりは、地方に分割された統治をさせるようになっていく。そして、寒冷化でまた政権が変わると言うのが面白い。
最近の歴史の本を見ると、単なる権力者の行動の結果だけでなく、地理や気候も研究の対象になっているのが非常に面白い。
江戸時代に入ると分業が進み経済が発展することで人口も増えていっている。
明治に入って、日本と中国の西洋に対する対処の仕方が、国家体制とか文化にかなり依存していて、それが行動に大きくなる影響しているのが非常に面白かった。
日本は西洋から知識を得ていくために、日本に存在しない言葉や概念を漢字に置き換えて翻訳していった。日本は単一民族国家で文化的なまとまりがあったので、漢字に置き換えれば全国的に学ぶことができた。
一方で、中国は、元々、さまざまな民族の集合体であるので、新しい言葉をそのまま全国に広めることができなかった。どうするかというと、中国の昔からある概念に置き換えて、広めていく。附会というらしい。
なので、西洋の本質的な理解には及ばなかったし、過去の古い物をづっと維持し続けなければならなかったらしい。
これは、なんとなく現代の韓国が、なんでも韓国に起源がると主張しているのと似ているなと個人的には思った。自国の何かと紐付けないと外部の価値あるものを価値あるものとして輸入できない文化的事情がある。なぜなら他民族で文化がバラバラだから、すでに共通の価値認識があるものに置き換えないといけないのだ。
日本以外のアジア諸国に共通する部分らしい。
また、沖縄は昔から日本かというと、そんなことはなくて、本当に明治まで独立国家で、中国にも従っていたが、日本にも従っていて、微妙な立ち位置の独立国だったようだ。
それを日本が併合して、琉球王朝が消滅したのが150年前くらいなのだから、ほんとに最近だ。
そして、日本は同じようなことを台湾にもしようとしていた。
中国の国家としての特性や日本との違い、沖縄の状況など非常に面白い本ではあった。
文章の書き方や論理だての方法の本というよりは、レトリックの種類を集めて紹介するような内容になっている。
薄い本だし、仕方がないとは思うが、入門というよりは概要といった方が適切な気がする。
これを読んだところで文章を作るのが上手くなるとも思えない。
Googleでのソフトウェア開発がどのように行われているのかを解説した本。
正直、特別なことは何もない、当たり前のことを当たり前にやり続けた結果の積み上げがあるのだなと納得する。
一時期、Googleではマネージャーを廃止したこともあったらしいが、リームリーダーに関してかなりのページを割いているのは面白い。
また、設計等については特に言及していない。あくまでも重要なのはコードで、それを継続的に発展させるためのツールとしての設計があるだけという印象。あくまで製品に集中しているのがわかる。
手元において、迷った時に読み返したい本だと思う。目次だけでも記載しておく
第1部 主題
1章 ソフトウェアエンジニアリングとは何か
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部 文化
2章 チームでうまく仕事をするには
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章 知識共有
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章 公正のためのエンジニアリング
4.1 バイアスこそがデフォルト状態である
4.2 ダイバーシティの必要性を理解する
4.3 多文化理解の能力を育む
4.4 多様性を行動可能なものにする
4.5 一本槍のアプローチは退けよ
4.6 確立されたプロセスを疑え
4.7 「価値観」対「結果」
4.8 好奇心を持って突き進め
4.9 結論
4.10 要約
5章 チームリーダー入門
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章 スケールするリーダー
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章 エンジニアリング生産性の計測
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.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章 コードレビュー
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章 ドキュメンテーション
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章 テスト概観
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章 ユニットテスト
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章 テストダブル
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章 大規模テスト
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章 廃止
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 要約
第4部 ツール
16章 バージョンコントロールとブランチ管理
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章 Code Search
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章 ビルドシステムとビルド哲学
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章 GoogleのコードレビューツールCritique
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章 静的解析
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章 依存関係管理
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章 大規模変更
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章 継続的インテグレーション
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章 継続的デリバリー
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章 サービスとしてのコンピュート
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 要約