概要
オライリーから出ている 「Googleのソフトウェアエンジニアリング」
を読んだので以下のような内容について章ごとにメモする。
- 主張されている内容の概要、
- そこから得られたノウハウ、
- その他の感想。
なお、全て個人的な解釈に則って記事を書いており、ノウハウ抽出に不要な部分は大胆にカットしているので、本の内容の詳細は実際に読んで把握することをお勧めします。
個人的に印象に残った章
- 2章
- 7章
- 12章
第1部 主題
1章 ソフトウェアエンジニアリングとは何か
概要
プログラミングとはコードを生産する行為、ソフトウェアエンジニアリングとはそのコードを保守することまでを含んだ時間的な広がりを持つ行為。
対象が違うのだから、プログラミングとソフトウェアエンジニアリングに同じベストプラクティスが通用すると一般に仮定するのは無理。
ノウハウ
以下のHyrumの法則というものが紹介されている。
あるAPIに十分な数のユーザーがいるとき、APIを作った者自身が契約仕様として何を約束しているかは重要ではない。
作られたシステムが持つあらゆる観察可能な挙動に関して、それに依存するユーザーが出てくるものである。
したがって、API仕様書に書かれていない変更をする際にも、ユーザーへの聞き取り調査の工数は含めておくのが望ましい。
感想
他にも、スケールする仕組みをつくろう、手戻りを無くすよう早期に問題を発見しよう、とかそんなことが書かれていた。
第2部 文化
2章 チームでうまく仕事をするには
概要
チームで仕事をするには謙虚と信頼が大事だ、等の一般的によく言われることが書かれていた。
ノウハウ
以下の標語が紹介されている。
早期に失敗し、高速に失敗し、頻繁に失敗せよ
これを実践するために、一人で黙々と作業するのは止める。誰かに頻繁にフィードバックを求める。
感想
「バス係数」の概念も紹介されている。これは何人のメンバーがバスで轢かれたらプロジェクトが失敗するかという指標。
バス係数が低いと、真面目な人ほど他の人に迷惑がかかるからという理由で休みづらくなる気がする。
それで無理矢理プロジェクトを回すのは絶対によろしくないので、迷惑を顧みないほどの豪胆さが欲しい。
自分は休めるし、プロジェクトが回らなければ上にも人手の必要性が伝わるしで一石二鳥である (実行可能なノウハウかどうかは諸説あるので感想部分に書いた)。
3章 知識共有
概要
心理的安全性は大事だとか、知識共有を率先してやることに報酬制度を設けよとかの一般論と、Google内でのレビューフローの事例等が書かれていた。
ノウハウ
特になし。
感想
Googleの事例自体は参考になるが、銀の弾丸は無いとも書かれており、結局は自分の組織に合った方法論を構築する必要がある。
そういった意味ですぐに実行可能なノウハウは無かった。
4章 公正のためのエンジニアリング
概要
バイアスは常にある、多様性が大事、といったことが書かれていた。
GoogleのAIが黒人とゴリラを間違えて問題になった件とか、その類の話。
ノウハウ
特になし
感想
それはそう。くらいの感想だった。
5章 チームリーダー入門
概要
リーダーとしてどんなことをするべきかが書かれていた。
ノウハウ
章自体がノウハウ集となっているので多すぎて書ききれない。
最も重要だと感じたのは「サーバントリーダーシップ」というキーワードで、可能な限りチームメンバーに仕事を移譲し、
自身はチームメンバーが円滑に仕事をすることができるように仕える、というもの。
感想
リーダーになる機会がもしあれば読み直したいが、社内政治が混沌としていたりするとそう上手くは行かないんだろうなと感じた。
6章 スケールするリーダー
概要
スケールするリーダー (リーダーのリーダー等) としてどんなことをするべきかが書かれていた。
ノウハウ
これも章自体がノウハウ集となっているので多すぎて書ききれない。
最も重要だと感じたのは「いつでも立ち去れ」という標語。結局リーダーがボトルネックになったら意味ないよねということで、
自分が立ち去っても問題なく動くチームにするべきで、具体例として1週間以上休暇を取っても問題なく機能するか等が挙げられていた。
感想
5章と同じ。
7章 エンジニアリング生産性の計測
概要
生産性を計測する際の注意点が書かれていた。
ノウハウ
ゴール、シグナル、メトリクスを明確に区別する (GSMフレームワーク)。
- ゴール: 達成するべき目標。
- シグナル: ゴールを達成したことを知る手段。必ずしも計測可能である必要はない。
- メトリクス: シグナルの計測可能な代替品。
メトリクスを計測する前に、それを計測した後どう行動するのかを考えるべき。
生産性のゴールにはトレードオフがあるため、一部だけを計測するのはよくない。
QuANTSのゴールを全て計測することで、網羅的に計測ができる。
| 頭文字 | 英語 | 日本語 |
|---|---|---|
| Qu | Quality of the code | コード品質 |
| A | Attention from engineers | エンジニアの注意 |
| N | Intellectual complexity | 知的複雑性 |
| T | Tempo and velocity | テンポと速度 |
| S | Satisfaction | 満足 |
感想
生産性向上はよくある組織目標だと思うが、ちゃんと考えたことは無かった。
特にGSMの区別はちゃんとしてみたい。
第3部 プロセス
8章 スタイルガイドとルール
概要
コーディングスタイルガイドやコードフォーマッター大事だよねくらいのことが書かれていた。
ノウハウ
特になし。
感想
そこまで新しい知見はなかったので感想も簡素。
9章 コードレビュー
概要
コードレビューにおける恩恵や、Googleでの実施方法などが書かれていた。
ノウハウ
特になし。
感想
よくあるプルリクエストのベストプラクティス (変更は小さくしろ、レビュアーのことを考えろ、できることは自動化しろ等) とほぼ変わらない印象だった。
10章 ドキュメンテーション
概要
ドキュメントがいかに大事かということ、ドキュメントの管理について、Googleでの実例等について書かれていた。
ノウハウ
ドキュメントにはオーナーを付ける。
オーナーがドキュメントの変更をレビューして反映たり、最新化する責任を持つ。
ドキュメントはVCSで管理し、ソースコードと同じ管理方法にする。
感想
Googleでもドキュメントについては改善途中であるらしい。ドキュメントが乱立して陳腐化するのはどこでもよくあることで、それを避けるためにオーナーを付けるのは必須だと感じた。
11章 テスト概観
概要
テストは大事だくらいのことが書かれていた。
Googleでのテストは「単体」や「結合」等の文脈では区別されず、テスト規模のみにより大中小に分類されるとのこと。
| テスト規模 | 主な制約 | その他 |
|---|---|---|
| 小 | 単一プロセス | sleep禁止、I/O操作禁止、ブロッキング禁止 |
| 中 | 単一マシン (複数プロセス) | localhost意外へのアクセスが禁止 |
| 大 | 複数マシン | 実質制約なし |
ノウハウ
破綻してほしくないものは全部テストすべき。
ビヨンセルールと呼ばれる標語に従っておく。
「そんなに好きならそいつにテスト付けときゃよかったのに」
感想
概観というだけあってノウハウ的なところは薄かった。
12章 ユニットテスト
概要
ユニットテストの範囲、保守性について、書き方についてが書かれていた。
脆いなテスト (無関係な要因でたびたび失敗してしまうテスト) を避けることや、テストにロジックを入れない等の一般的なことが多かった。
ノウハウ
脆いテストを避けるために変化しないテストを目指す必要がある。
そのためには公開API経由でテストすることが重要である。
公開APIの定義とは、以下の通りである。
我々が文章の文脈で「公開API」と述べる場合に実際に言及している対象とは、
ユニットコードのオーナーであるチームの外部にいるサードパーティに対し、そのユニットが公開しているAPIだ。
これに従えば、WEBのAPIをチーム外に公開している場合、そのAPI内部の実装をメソッド単位でテストするべきではない。
そのようなテストは外部との契約に関係がないリファクタリング等で失敗するようになる。つまりは脆いテストである。
感想
メソッド単位でテストするなというのは衝撃があったが、納得感もあった。
これに関しては別記事にしたいと思っている。
13章 テストダブル
概要
テストダブルとはテスト時に使われるモックやスタブのこと。
テストダブルの種類や利用法についてまとまっていた。
ノウハウ
テストではなるべくテストダブルは使わず、本物の実装を使う方が良い。
テストの実行時間高速化等のメリットと、テストダブルを使用した際のリスク等のデメリットをトレードオフし、適切な場合にのみテストダブルを利用するべきである。
感想
メソッドやクラス単位でテストしようとするとどうしても依存が複雑な場合はモックだらけになってしまう気がする。
前章に従ってメソッド単位でテストせず公開API経由でテストする場合には有効なノウハウに感じた。
14章 大規模テスト
概要
大規模テストを実施する場合の考え方について書かれている。
ノウハウ
優れた設計には、リスクならびにそのリスクの軽減のための大規模テストを見極めるテスト戦略が含まれている。
つまり、設計の時点で起こりうるリスクを考え、それに対する大規模テストについて考えを巡らせておくべきである。
感想
大規模なテストは辛いことが多いが、それでもメリットと天秤に掛けるべきだよねという当たり前なことに気付かされた。
大規模テストを作成する際にもう一度読み返したい。
15章 廃止
概要
ソフトウェアの廃止は構築よりも難しいことが多いが、それでも保守コストと天秤に掛けて実施すべきということと、
その際に注意すると良いことについて書かれていた。
ノウハウ
特になし。
感想
廃止についてはGoogleだからといって特別良いノウハウがあるわけではなく、結局難しいままなんだなと感じた。
第4部 ツール
16章 バージョンコントロールとブランチ管理
概要
バージョンコントロールの概説、ブランチ管理のバッドノウハウ (長寿命のdevブランチはNG) 、リポジトリ間の依存関係について書かれていた
ノウハウ
特になし。
感想
Googleのモノレポについて少し書かれていたが、なかなか真似しづらいので、もしモノレポ環境になったら読み直そうと思った。
17章 Code Search
概要
Googleのコード閲覧、検索のための社内ツールであるCode Searchについて書かれている。
ノウハウ
特になし。
感想
社内ツールについては得られる物が少なそうだったので斜め読みした。
18章 ビルドシステムとビルド哲学
概要
ビルドシステムの一般的な事柄について書かれていた。
ノウハウ
特になし。
感想
一般人はよくあるビルドツールでビルドすることになると思うのでここも読み飛ばした。
ビルドツールを作る側になったら読み直したいと思う。
19章 GoogleのコードレビューツールCritique
概要
Googleのコードレビューツールのための社内ツールであるCritiqueについて書かれていた。
ノウハウ
特になし。
感想
ここも社内ツールの話なため読み飛ばした。
20章 静的解析
概要
静的解析の概説とGoogleの社内ツールであるTricorderについて書かれていた。
ノウハウ
特になし。
感想
ここも社内ツールのため省略した。
静的解析も既製品を使うことがほとんどだと思うので、作る側になったら読み直したい。
21章 依存関係管理
概要
依存関係をいかにして管理するか、およびセマンティックバージョニングについて書かれていた。
ノウハウ
特になし。
感想
これも依存関係管理ツールを作る側になったら読み直したいと思った。
セマンティックバージョニングの限界や最小バージョン更新戦略というものを使うと良いということも紹介されていたが、そこまで役に立つものでもなかったので感想欄に。
22章 大規模変更
概要
Google全社で実施されるような大規模変更について書かれていた。
ノウハウ
特になし。
感想
Google規模で大規模一斉変更を指揮するような機会は一生来ない可能性の方が高いので斜め読みした。
23章 継続的インテグレーション
概要
CIについて、テスト実施のタイミング、GoogleにおけるCIについて書かれていた。
ノウハウ
マージ前に実施するべきテストとマージ後に実施するべきテストがある。
開発の高速化のために、マージ前は信頼性が高く高速なテストのみを実施し、マージ後は中大規模テストのような時間がかかり多少不安定でも許容されるテストを実施するべきである。
感想
ノウハウには入れていないが以下のような文言があった。
CIはアラートである。
アラートはSLOが健全であることを担保し、CIはビルドが健全であることを担保する。
この対比は新しく、まだ模索中のようだが、一理あるなという気はした。
24章 継続的デリバリー
概要
CDやリリースに関するベストプラクティスが書かれていた。
ノウハウ
問題を早期に切り分けられるように、あらゆる機能をフラグで保護すべきだ。
各リリースのリスクを低減しつつ、市場に投入するまでの時間を最小化するために、早期かつ頻繁に小さなバッチでリリースすべきだ。
感想
機能フラグに関してはサービス全体の観点では同意するが、分業しているとなかなか難しいような気もした。
一方でリリースを早期に小さなバッチで行う方がより安全であるというのは同意できる。
25章 サービスとしてのコンピュート
概要
PaaSやCaaS、サーバーレス等のコンピュートリソースについて書かれていた。
ノウハウ
特になし。
感想
組織のコンピュートリソースを選択するような立場に無いので流し読みしたが、特に目新しいことは書かれていなかったように思う。
まとめ
Googleは世界トップの企業で、その内部について良くまとまっていました。
興味がある人は是非本を読んでみてください。