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

書籍ページ

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

メモ

Googleにおけるソフトウェアエンジニアリングの成功と失敗の事例から各テーマにおける本質をまとめた書籍

600ページ以上あり結構長いので方針としては第１部だけは一通り読んでみて、その先は各章結論から読んでいき、気になった部分だけ遡って拾い読みしていく戦略でいく方が良さそう。

この手の本は何が書いてあるかだけ脳内にインデックスを貼り、後々自分に刺さりそうな時期に再度該当箇所を読み直す方が効率が良い。

海外発の書籍には珍しく冗長な文章が少なく端的で鋭く本質をまとめた文章が多くなっているのが非常にGoogleらしい。コラムも面白いし脚注も解説が親切で助かる。これは翻訳者のお陰かもしれない。

"Googleの"とか付いてる書籍はどうせ自分の身の丈に合わないだろうと思い、読まずにいたが完全に間違ってた。特に第1,2部に関しては所属する組織の大小に限らずソフトウェアエンジニアとして心しておくべき至言が多く良かった…

第１部

プログラミング(開発)とソフトウェアエンジニアリング(開発、修正、保守)という線引きについて

いきなり核心の話で抉られる。この手のAIの自動生成ではプログラミングはできるかもしれないがエンジニアリングは現状だとまだ難しそうというのが言語化できて良い。

このブログ(どのようにしてプログラマはAIに仕事を奪われていくかの妄想)でも書いたが保守とか長い時間軸で見た場合の仕事をプログラミングではなくエンジニアリングと呼べば良いのか〜という気づき。

前者はコードを生産するもの、後者は生産したコードを有用性のある稼働期間中に保守するようにプログラミングを拡張する

時間

ソフトウェアエンジニアリングはプログラミングではない

プログラミングに時間の概念が加わると全く別物になる。時間の考慮がプログラミングとソフトウェアエンジニアリングを分かつ。

≒時間で積分したプログラミング

Hyrumの法則

あるAPIに十分な数のユーザーがいるとき、そのAPIを作った者自身が契約仕様として何を約束しているかは重要ではない。作られたシステムが持つあらゆる観測可能な挙動に関して、それに依存するユーザーが出てくるものである。 - １章ソフトウェアエンジニアリングとは何か p9

存続可能期間によるプログラミングスタイルの分類

スケール

プログラミングは個人的な創造、ソフトウェアプログラミングはチームの努力の成果。

トレードオフ

利害の有無

変化の必要性、果たして必要なのか

変化のために変化すべきではない。実務上、変化に備えておく必要のないソフトウェアはほぼない(依存性の問題、セキュリティの問題などほとんど更新は避けられない)。

停滞は選択肢の１つだが賢い選択肢ではない

結局はあらゆる変化に対応しやすくしとくにはどうするべきかが常に問題、か

Beyoncéルール

インフラのCIのテストにない理由で発生した問題は気にしない => 気になることはCIのテストに書いておけ

シフトレフト

ソフトウェアやシステムなどの開発サイクルで品質保証のためにテスト工程を前倒しで行うアプローチ

エンジニアリング上の優れた決定

あらゆる入力情報(と少しの仮定)に基づいてトレードオフを考慮すること

全てに理由が存在しなければならないという思想

なんとなくの感覚で施作決定される現場ありがち

コンテキストの変化により決定の変更が必要になる場合も

間違い認める能力の重要性

第２部

天才神話

日本人好きなやつだ。大抵はチームの方が圧倒的に天才を凌駕するという。

リーダビリティ

コードの読みやすさ以上の、プログラミング言語のベストプラクティスとコーディングスタイルを体現する明確でイディオムに富んだ保守性のあるコードを一貫してかけることをリーダビリティがあると呼ぶ

このレビューが全社的なベストプラクティスを新人の社員などにも伝えるためのメンター制度的な側面もある。

情報共有するための読みやすさという観点。

go/HogeHoge のリンクで社内向けのカノニカルWikiが作成されるの良い。Scrapboxとかはその感じで使えるタイプではある。

技術書で公正というテーマが出てくるの初めて見た

どんなユーザーに対しても適切な製品になる試みが必要というのはこの規模の企業になるとまぁそうだよなと思う。

Blueskyの差別的なユーザ名を獲得する集団への規制みたいなものも、運営は軽視してたが結構問題になっていてこの辺の公正感みたいな意識が必要そう。

リーダー(managerとtech leadと時々ic)について

HRT/社交性/チームと外

チームのためのサーバント

ワインバーグのスーパーエンジニアへの道にもリーダーについては似たようなことが書いてあった記憶

DIYせずチームに移譲する(自分でやった方が早い病)

真に優れたリーダーへ

トレードオフ!!!! 意思決定!!!!

「本物」の休暇を取る: 週末休みは休暇ではない。自分の仕事を「忘れる」には最低 3 日はかかる。

90分周期で脳は動作してる

Basic rest–activity cycle - Wikipedia

これレベルになるとチームのマネージメントと共に自分自身をもマネージメントしないといけない。やること多すぎる...

生産性の向上と計測

Google社内には生産性改善を専門に扱う研究者などが含まれたチームがあるの強い...

至言

計測に成功しているという場合、それは仮説が正しいか誤りかを証明する糸口をつかんだという話ではない。計測の成功とは、決定を行うのに必要なデータを利害関係者に与えているということである。その利害関係者がそのデータを使わないのであれば、その計測プロジェクトは常に失敗だ。計測結果に基づいて具体的決定がなされるであろう場合にのみ、計測を行うべきである

GSMフレームワーク

Goalとそれを証明するSignalとそのSignalをどのように計測するのかというMeasurementという指標

webのリソースだとあんまりまともな解説サイトなかったがこれが一番まとまってはいそう

What Is the Goals-Signals-Metrics Process and How To Track It?

第３部

スタイルガイドとルール

なぜ必要？良い・悪いの判断を行うための価値基準を定めるため。

一貫性

一貫性があれば大規模組織になっても比較的少ない努力で多くのエンジニアが仕事をやり遂げられる

一方で例外への譲歩も重要

パフォーマンスの最適化とか。

gofmtしかりGoogleは早くから大規模組織でシステム開発を行うこととその課題を認識し、そしてそれを課題として捉えており、解決法を探ってきた企業なのでこういうツールが生まれるのだろうと思った。