2021年11月末に発売されてからすぐに入手したはずですが、少しずつしか読み進められず、先日ようやく読み終わりました。
25章ある書籍の内容をざっくり分類すると
- トップ層のエンジニアを集め、実業務を通じてGoogleが分析・見出したベストプラクティス
- Googleの規模でないと起こらないであろうスケール問題
- Googleにしかなさそうな謎内製ツール/謎内製ソフトウェアの紹介
かなと思います。
中堅以上のソフトウェアエンジニアなら技術的にも思想的にも面白いと感じるポイントが必ず見つけられ、頭から読み進めずとも気になる章をつまみ食いして読むこともできる面白い書籍です。
以下気になったトピックを順不同で紹介します。
Hyrumの法則が面白い
Hyrumさんはこの書籍の著者で、こんな考えを披露しています。
あるAPIに十分な数のユーザーがいるとき、APIを作った者自身が契約仕様として何を約束しているかは重要ではない。 作られたシステムが持つあらゆる観察可能（observable）な挙動に関して、それに依存するユーザーが出てくるものである。
「要件として合意した」「仕様として明記している」とかに関わらず、暗黙的な挙動に依存した実装になってしまっていることはよくあります。 有名なところだとハッシュの順序問題とか。「OSSライブラリを更新するとテストが通らなくなった」も同種の問題かと思います。
実装だけで起きるのではなく、組織のあらゆるレベル・コミュニケーションでこのような暗黙的な依存が発生するのが、法則としてよくできているなと感じます。
マネジメントについて
・自分が居合わせなかったとしても組織自体がその問題を解けるようにすることも、自分の仕事である
・優れたマネジメントの95%は観察と傾聴で、5%はちょうど正しい場所に決定的に重要な調整を加えることである
GoogleのマネジメントスタイルはGoogle re:Workとしてもまとまっていますが、エッセンスが短くまとまっている上記の書籍表現が気に入りました。 マネージャーとしてチームやメンバーと伴走することも時にあるかもしれませんが、自分がいなくても同じように物事が動くよう仕組みを作るのが一番効果的ですよね。
テストコードの読みやすさ
・テストは後からの付け足しであってはならない。
・テストコード自体のテストはかかれないため、テストコードでは分岐・繰り返しなどの制御構文を使うべきではない。
・なるべくモック使うな
Googleの開発規模・エンジニア数ともなると、不安定なテストが少量でも入ると、他の開発者の時間を奪ったりリリースブロックとなり得たりと与える影響がものすごく大きいことが心に残っています。なので当初からテストをきちんと書くし、テストコード自体も読みやすさを重視するし、なんならモックをなるべく使わずテストすることを考えるそうです。
テストをしっかり書こうとするほどモックの書き方に時間が取られているような気がしていたので、「モックを使いこなすことが必ずしも良いことではない」という意見があることが知れてよかったです。
レビューは設計を議論する場ではない
・コードレビューは、過去に既に行われた設計上の決定について討議するための時間ではない。
・コードレビューは提案されるAPIの設計を紹介するための時間ではない。
コードレビューの目的が事前に擦り合わせられていないと、つい設計方針や実装技巧の議論をしがちではありますが、レビューはそういう時間ではないと一刀両断してくれました。そうですよね。
ドキュメントは読み手を意識して書く
・(ドキュメントは)読者に向けて最適化せよ。
ドキュメント整備について、Googleは他社よりも時間・工数をかけているのだろうと思っていて、書籍を読み終わった今もその認識ですが、それでも完璧ではないと感じているそうです。ドキュメントは「Googleでも一級市民として扱われていない」だとか。
ドキュメント管理は定期的に新しいツールが出てきますが自分の中ではこれといった決定版と受け取ることができず、内容が古びたものを見直し・淘汰できる仕組みが入っているといいのかなーと思ったりしました。
ソフトウェア開発に関する意識の持ち方
コードは債務であり資産ではない。
「技術的負債」という言葉が広く使われるようになったせいか、負債でないなら資産なのだろうと私とかは考えてしまいがちですが、本書では運用・メンテナンスが必要なことから「債務」と表現していました。利用者が使い続けられるように考慮・サポートが必要なことからですが、先に紹介したHyrumの法則にもつながる考え方かと思います。
定期的な再デプロイの強制化
本番環境には半年ごとに再ビルド・再デプロイされなければならない
だそうです。
開発がひと段落したサービスだとライブラリ更新を怠ったり、頻繁に更新されないサービスだとビルド・デプロイの自動化を後回しにしてしまいがちですが、こういうルールを決めておくことで問題を軽減することができそうです。外部環境の変化でいつのまにかデプロイできなくなった/動かなくなったというのも避けやすくできそうです。
Bazel / アーティファクトベースのビルドシステム
モノレポ(全てのコードを1つのリポジトリにまとめて管理する)とセットで導入するビルドシステムとしてよく名前を聞いていましたが、アーティファクトの依存関係を宣言的に定義しておくことでツール側で再ビルドの必要性を正しく判断でき、ビルドに要する時間を短縮できると知り、仕組みにとても感心しました。Bazelについて調べてみると、現実は「Bazel職人」のようなノウハウを蓄えている人が生まれてしまう負の側面もあるようですが、それでも機会があれば一度は触ってみたいなと思うように考えが変わりました。
おわりに
少しずつ読み進めていたため、Twitterに #Googleのソフトウェアエンジニアリングのタグで感想を呟いていましたが、書籍で推奨しているハッシュタグは #swebookjpだということを一番最後に知りました。ぜひ両方のハッシュタグを眺めてみて、書籍を手に取ってみてください。
