Spinach Forest

Book: Software Engineering At Google

|

Software Engineering at Google: Lessons Learned from Programming Over Time: Winters, Titus, Manshreck, Tom, Wright, Hyrum: 9781492082798: Amazon.com: Books

今月のプロジェクト。いちおう読み通した。が、しょうじきだいぶ読み飛ばした。面白くなかったので・・・。

まず最初にこの面白く無さについて分析したのち読みどころを振り返りたい。

結局のところ、ソフトウェアエンジニアリングの原則みたいのは会社固有の部分はなく、あるとしても理不尽なスケールや時系列といった大企業税由来のうんざりするものばかりで、面白くない。面白いのはそういうのと戦うための具体的な工夫。だから Part 4 Tools は相対的には面白いのだと思う。説教はいいからお前らのやったことを教えろ!という。

とう点で面白かったのは ...

そのほか面白いというか、ふーんという気持ちになったのは


一歩下がって、プログラミングの時間積分としてのソフトウェア工学というメタファについて考える。

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 を受け入れるのは違う気がするので、もうちょっと違う視点を探求していきたい。なんちゅうか、こういう「伝統的」ソフトウェア工学よりはクラウドとかデータサイエンスとか、あっち方面の発展に目を向ける方が発見がありそうじゃん?