「Googleのソフトウェアエンジニアリング」を読んだ
目次はこちら
第1部 主題
1章 ソフトウェアエンジニアリングとは何か
第2部 文化
2章 チームでうまく仕事をするには
3章 知識共有
4章 公正のためのエンジニアリング
5章 チームリーダー入門
6章 スケールするリーダー
7章 エンジニアリング生産性の計測
第3部 プロセス
8章 スタイルガイドとルール
9章 コードレビュー
10章 ドキュメンテーション
11章 テスト概観
12章 ユニットテスト
13章 テストダブル
14章 大規模テスト
15章 廃止
第4部 ツール
16章 バージョンコントロールとブランチ管理
17章 Code Search
18章 ビルドシステムとビルド哲学
19章 GoogleのコードレビューツールCritique
20章 静的解析
21章 依存関係管理
22章 大規模変更
23章 継続的インテグレーション
24章 継続的デリバリー
25章 サービスとしてのコンピュート
第5部 結論
Googleのエンジニアが社内でいままでにどのようにソフトウェアを開発し、レビューし、テストし、ドキュメンテーションし、デプロイしてきたかを書いた本で、一人の著者が書いたわけではなくて章によって分担して書かれている。600ページを超える大著。
この手の本だと、Googleじゃないとできないよね？みたいに感じられる部分が多少あるのはしょうがないかなと思いつつ、Googleも最初から今のようであったわけではなく、徐々に改善していったことも伺える。
例えば1章でそんなような話が出てくる。
ここでHyrumの法則が紹介されている。
ある API に十分な数のユーザーがいるとき、API を作った者自身が契約仕様として何を約束し ているかは重要ではない。作られたシステムが持つあらゆる観察可能(observable)な挙動に関して、それに依存するユーザーが出てくるものである。
ああ、そうだよね、あるよねと思いつつよんでいき、一つの例としてハッシュテーブルの要素をiterateするときにアプリ側は当然その要素の順番に依存した実装をしてはいけないわけだが、膨大なコードベースがあるときにはたして全部依存してないといえるのか？
Googleは2006年にコンパイラーのアップグレードをした際にその作業は苦渋の極みとなったそうだ。しかし
G o o g l e が本当に非凡であったのは、アップ グレードのタスクが苦難に満ちていたという事実を受けて、スケーリングの問題を克服しスケール を我々の長所に変えるべく、技術と組織の変化の必要性を認めた上でそこに注力し始めたことだ。
Googleが共通インフラをいかに重要視、投資しているかは他の章を読んでいてもわかるし、例えば、18章 ビルドシステムとビルド哲学の最後の結論で、エンジニアの権力と柔軟性を制限することによって生産性を上げたとあって、やはり共通部分の開発にリソースさけるのは強い。
一方でGoogleがまだ完全に対処したとは言い難く改善途中なのかなという話が4章の「バイアスこそデフォルト状態である」で、2015年にGoogle Photosの画像認識アルゴリズムが黒人を「ゴリラ」と分類するという大きな問題を起こした。この理由はアルゴリズムのデータセットが母集団を正しく表現していなかったことからくる。
これほど大問題になるケースはそこまで多くないだろうけど、例えば何かの認識アルゴリズムを使うソフトウェアのドッグフーディングを社内で行ったけど、そもそも社内だとエンジニアが大半で、エンジニアだとその国の男性が大半というケースはありそう。
第2部文化は具体的なソフトウェアとかツールではなくて、チームとかリーダーとかそういう話が中心で、5,6章あたりは僕の今のrole(Techinical Program Managerが近いと思う)と関連するところもあり、興味深く読んだ。まあ新しい発見は特になくてそうだよねという感じではある。そして6章でこんまり（近藤 麻理恵）が登場してた。
第3部プロセスはコードレビュー、ドキュメンテーション、テストの話。Googleはドキュメンテーションにwikiを使うのをやめてmarkdownで書いてソースコード同様repository管理にしてるのね。
15章 廃止 で、コードは債務であり、資産ではない。なぜならコード自体は価値をもたらさず価値をもたらすのは、コードが提供する機能だからとあって、確かにな、となるなど。
第4部ツールは割りと読み飛ばしたが22章大規模変更で出てきたApache Commonsライブラリの脆弱性はこれっぽい。デシリアライズ時にRCEになる。https://nvd.nist.gov/vuln/detail/CVE-2015-6420
去年末騒がせたLog4J問題を思い出してしまった。
https://nvd.nist.gov/vuln/detail/CVE-2021-44228
以上、ざっくりと感想めいたことを書いたけど、総じて勉強になる本だったし、やはりソフトウェア開発においては基本的な改善を着実に進めていくのが（どんな企業規模であれ）大事なのだなと感じさせられた。
