Book: Software Engineering At Google
今月のプロジェクト。いちおう読み通した。が、しょうじきだいぶ読み飛ばした。面白くなかったので・・・。
まず最初にこの面白く無さについて分析したのち読みどころを振り返りたい。
- 面白く無さの一旦が自分にとっての新規性の無さなのは間違いない。仕事でやらされていることの話なわけで。これは自分の問題だから、まあいい。
- とはいえ内容の新規性のなさはある。たとえば "Chapter 2. How to Work Well on Teams” とかさ、あなたそれ本一冊書いてるじゃん既に。読んだよ。
- リーダーシップの話とかも、ここで書かずに自分で本書いてくれ、という気分になる。内容が悪いとは言わないけど、ミスマッチ。
- 自動テストの話に四章割いているが、それも世の中にたくさん本出てますから。十年以上前に。もういいよ。
- 基本的に Part 2. Culture と Part 3. Process はこの「もうその話は聴きたくない」食傷気味の話がおおくて厳しい。Part 4. の Tools は割と良い。
- 書き手によってばらつきがあるが、文章が読みにくい。冗長だったり、いいわけがおおかったり、大仰だったり。読ませる文章(!=正しい文章)を書く力はソフトウェア・エンジニア能力のメインではないので仕方ないが、こっちは金を払って業務外の時間で本をよんでるので退屈だと辛い。仕事じゃないんだからさ、面白くないと読みたくないよ。
結局のところ、ソフトウェアエンジニアリングの原則みたいのは会社固有の部分はなく、あるとしても理不尽なスケールや時系列といった大企業税由来のうんざりするものばかりで、面白くない。面白いのはそういうのと戦うための具体的な工夫。だから Part 4 Tools は相対的には面白いのだと思う。説教はいいからお前らのやったことを教えろ！という。
とう点で面白かったのは ...
- Part 4 Tools. 特に Code Search (Ch 17), Build System (Ch 18), Code Review (Ch 19), Static Analysis (Ch 20), Large-Scale Changes (Ch 22) はよい。
- 賛否はさておくと Version Control (Ch 16), Dependency Management (Ch 21) はまあ、そういう結論になっちゃったんですよね・・・みたいな感想戦的読みごたえはる。
- CI の話は特に面白くない.
- Borg の話もなぜか面白くない。Kubernetes でも勉強したほうが良いわ、みたいな気分になる。
そのほか面白いというか、ふーんという気持ちになったのは
- What is Software Engineering (Ch 1). 例の "Software Engineering はプログラミングの時間積分である" という話。この定義は Russ Cox も引用しているので、まあ知っといて良いかなと。
- しかしこの定義の説得力ある、かつ新規性のある application というのはぶっちゃけそんなにない気がする。（保守性大事ですねはいはい、みたいな。）そんななか Deprecation (Ch 15) はまさに時間積分の連続性を実現するプラクティスで、割とよかた。コードサーチして依存箇所を洗い出せとかいわれても困るけど、まあ我々そうやってますよ、そうですか、という腑落ち感はある。
- Knowledge Sharing (Ch 3). Google の knowledge sharing がどのくらい機能しているのかはさておき、go-link とか社内 SO もどきがあるみたいな話は Tools 枠として面白い。
- CD の章。やばい。YT は Python の monolith です、こういうプロジェクトのリリースは担当者がどんどん burn out していなくなります、と書いてあるが解決したとは書いていない。サーチのバイナリは週一回のリリースも危うくなったけれど著者ががんばって２日に一回まで持っていきました、と書いてあるがどうがんばったか書いてない。というか手動の QA が挟まってるとか全然 C に D してない。そのへんのダサさはまあ生々しさとして楽しむとしても、リリースの話でプロセスの章にいれておきツールの節にいれる話じゃないべ。なんかフラグツール自慢とかしてくれよせめて・・・。
一歩下がって、プログラミングの時間積分としてのソフトウェア工学というメタファについて考える。
15-20 年前くらいのソフトウェア工学って、こういうのではなかったよなあ、と思う。要件定義みたいのがあって、それと実装の関係をどうトラックするかとか、工数をどう見積もるかみたいな話があって・・・みたいなのだった。この大仰なソフトウェア工学は agile movement の台頭によりだいたい滅んだわけだが、一方で agile も割と宗教なのでいまいち工学的な力は弱く、結局 The Lean Startup のような要件探索のための business skill と、Devops movement のようなそれを支える operational skill に収束していった。そのあとに残されたものがこの「時間積分としてのプログラミング」なのではなかろうか。
要するに、CD/CI でばんばんコードを出していく時代に持続可能なプログラミングとはこういうものですよ、という。その結論の説得力は議論の余地があるとおもうけれども、そういう時代を前提にソフトウェア工学を議論しているのは、まあ意義があるんじゃないかな。ただやはり説得力が乏しいというか、あまりに大企業ウェイだなあと思う。
そして時間積分して角を丸めてしまうとプログラミングは過去 10 年くらいあまり進歩してなくて、新しいことは operational skill すなわち Devops とかそっちの方で起きているのだろうなあと、仕事に opts 成分のない身としてはやや残念な気持ちになる。同じ Google 本でも SRE のやつは広く読まれ、話題になった。
ただ時間積分しなければプログラミングの世界にもエキサイティングな瞬間はあり、それは React / GraphQL なのかもしれないし TypeScript / Rust / Wasm なのかもしれないし async / await なのかもしれないし Kotlin/Swift なのかもしれない。こういう流行りものは時間積分しながら 10 年保守するコードベースの番人には興味のない話かもしれないけれど、日々の刹那を楽しみたいプログラマにとっては興味の中心である。この関心のズレが自分にとっての面白く無さの理由の一面に思える。
なので、この人たちががんばって世界の秩序を保ってくれているのに感謝しつつ、自分は日々の積分じゃないプログラミングを楽しませていただこうと思います。まあコードレビューもするし static analysis の warning もちゃんと直すから許してちょ。
自分も体裁として肩書は Software Engineer なので出世という観点でみるとたぶんこういう "Software Engineering" は必要なのだと思うけれども、なんとなくこの integral bureaucracy を受け入れるのは違う気がするので、もうちょっと違う視点を探求していきたい。なんちゅうか、こういう「伝統的」ソフトウェア工学よりはクラウドとかデータサイエンスとか、あっち方面の発展に目を向ける方が発見がありそうじゃん？