こまぶろ

技術のこととか仕事のこととか。

ソフトウェアの複雑さに立ち向かう1つの哲学 :『A Philosophy of Software Design』 を読んだ

あけましておめでとうございます、になるはずだったのですが、後から読んだ『Googleのソフトウェアエンジニアリング』の方を先に記事にしたので新年2本目の更新です。

ky-yk-d.hatenablog.com

さて、本題。最近のお気に入りポッドキャストであるe34.fmで激賞されていた『A Philosophy of Software Design』を読みました。初版は2018年に出ていて、今回は2021年に出た第2版を読みました。

スパゲッティコードを想起させる装丁

scrapbox.io

どんな本?

書籍のテーマはソフトウェアの複雑さです。複雑さとは、システムを理解したり変更したりするのを困難にさせるものだと定義されています。そして、その兆候は、単純な変更がたくさんのコードの修正を強いてしまうことや、認知負荷(『Team Topologies』でも出てきましたね)が高まってしまうことなどに表れますが、最も深刻なのが「未知の未知」の発生だとされています。未知の未知は、バグの混入に容易に繋がってしまう一方で、定義上その存在に気づくことができないのでとても厄介です。

書籍では、このような複雑さを減らすためのさまざまな設計原則を紹介しています。このように書くと、設計原則のカタログのように見えてしまいそうですが、論述の展開は体系的で、さすが研究者の書いた本だという印象があります。

印象に残った箇所

Deep Modules と Shallow Modules

この本について語るときにはしばしば言及される部分ですが、モジュールをDeep/Shallowという軸で語るのは新鮮でした。Deepなモジュールの方がいいというのが本書の主張です。この区分は第4章で出てくるのですが、後続の章でも繰り返し言及される(「こうするとモジュールがDeepになるよ」などの形で)枠組みです。

インタフェース 機能(Functionality)
Deep 少ない 多い
Shallow 多い 少ない

※インタフェースが「多い」というのは、メソッドの多さや、あるメソッドの引数が多いことなどを指します。

General-purpose と Special-purpose

第6章くらいから出てくる軸で、「目下の必要を満たすよりも少しばかり(somewhat)一般的な目的に使えるように設計しましょう」というのが主張です。

この軸に関連して書かれていたこととして、ある処理(コード)がgeneral-purposeなのかspecial-purposeなのかを考えて、それらが混ざらないようにしましょうというアドバイスや、パフォーマンスに関する章(第20章)でのクリティカルパスからspecial-purposeな処理を取り除くとよいですよ、というアドバイスは印象に残りました。

コメントについて

「コメントを必要とするようなコードにしない」というのがよく言われることですが、この本では「そうはいってもコメントじゃないとできないことはあるでしょ」という立場からどういうコメントを書くのがいいのかを論じています。

個人的には有益だと感ずるアドバイスが多かったコメントについての論述でしたが、中でも印象に残っているのは、「コードよりも詳細を説明するコメントか、コードよりも抽象的なことを説明するコメントか」という区別です。コードの繰り返しに過ぎないようなコメントを書かないというのはよく言われることですが、詳細度という尺度をおいて、どっちの方向に寄せたコメントを書いているのかを意識するというのはとても役立ちそうな気がしました。

また、コメントを後で書くのではなく、設計の手段として最初に書きましょうという話がされていたのも印象に残りました。後から書こうとすると、コメントが実装の繰り返しになってしまったり、そもそもコメント書かなかったりということが起きがちですが、先にコメントを書くことでそれは設計の活動の一部となって楽しくなるし、抽象を考えることで設計の改善にもつながると言われています。

「インクリメントは機能ではなく抽象であるべき」

第19章では、オブジェクト指向(特に継承)、アジャイル開発、ユニットテスト、テスト駆動開発、デザインパターン、getter/setter といったトピックについて論じています。

よく聞く話も多かったのですが、アジャイル開発について論じているところで「the increments of development should be abstractions, not features」という記述があったのは印象的でした。インクリメンタルな開発をするときに、どのように設計を考えるかというのは大きなトピックですが、このような形でのアドバイスは初めてみました。続きの文章では、「抽象の必要に気づいたら、時間をかけて少しずつ作るのではなく、一気に設計しろ」と言っていて、あくまで「必要に気づいたら」ベースではありますが、開発対象の単位として抽象を主役として取り上げようという方向性は納得度はあるものでした。

全体的なスタンスについて

以上、印象に残った箇所をいくつか取り上げて紹介しました。個別のアドバイスについては「なるほどそういう考え方ができるのか」と思うところも多かったのですが、全体としては「今まで慣れ親しんできたのと結構違うスタイルだな」という印象も強く残りました。

大クラス主義?

上記のような印象を特に感じたのは、小さいクラスをたくさん作ることに全体的に否定的である点です。この書籍の中では、たくさんの小さいクラスを設けることは利用者にとってはインタフェースの多さ、ひいてはshallowなモジュールに繋がってしまいやすいものとされています。また、大きなクラス(メソッド)の方がファイルを行ったり来たりせずに一覧できるのでみやすい、という点にも言及しており、分割に対しては謙抑的なスタンスをとっています。

もちろん、「一つになっていた方が読みやすいんだから分割なんてするなよ」という雑な議論はしておらず、具体的な事例も交えつつ「こういうケースだとこういうデメリットがあるので分割しない方がいい」という丁寧な議論をしているのですが、自分は個人的には、責務の小さなクラスを多く作って組み合わせることで機能を実現する文化に親しんできて、分割前提でものを考えることが多かったので、(反発するわけではないですが)引っかかりながら読みました(それでこそ読む価値があるとも言えます)。

このような議論を展開するときには、著者はしばしばJavaの標準クラスライブラリを取り上げて批判します。Javaの標準クラスライブラリの一部に設計的にイケてないところがあるという話はしばしば耳に入ってくるので、言語の文化の話でもないのかもしれないですが、Ruby の特徴として「大クラス主義」というのが挙げられることがあるようで、文化(あるいは言語としての設計思想)の違いもあるのかなと思ったりしました(妄想)。

大クラス主義 クラス設計において一つのクラスにさまざまな機能を盛り込む方針。 Ruby の Array は、配列、リスト、タプル、集合、スタック(LIFO)、キュー(FIFO)などの機能を兼ね備えており、大クラス主義的と言える。

Ruby用語集 (Ruby 3.3 リファレンスマニュアル)

いや、これは多クラス主義でしょう。大クラス主義は結果的に少クラス主義につながります。

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/14664

私個人の印象ですが、小クラス主義で直交性が高いのは指数関数的な複雑さの原因になりやすいと思ってます。逆に大クラス主義でメソッドが多いのは線形の複雑さですね。私の好みはいうまでもないでしょう。

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/14675

ちなみに「大クラス主義」は海外では聞かない概念のようです。

なお、Java に近いコミュニティだと、『現場で役立つシステム設計の原則』の増田さんが以下のように「小クラス主義」と「大クラス主義」に言及していました。これは業務アプリケーションのバックエンドの設計の文脈で、書籍で出てくるUnixや言語の標準ライブラリの設計とはだいぶ前提としているものが違いそうなので、この文脈で「大クラス主義」「小クラス主義」という用語を用いることがどれだけ適切なのかは不明ではあるのですが。

なお、 id:snoozer-05 に「この大クラス主義ってのがRubyistじゃない自分にはよくわからんのですが」と聞いたところ、「『研鑽Rubyプログラミング』を読むといいんじゃないか」と言われました。確かに、関連する話が書かれているようなので、後で読んでみようと思います。

第 2 章「役に立つ独自クラスを設計する」では、いつ独自クラスを定義すべきか、 独自クラスへの SOLID 原則の適用、クラス設計でクラスを大きくすることとクラスの数を多くすることのトレードオフを扱います。 (『研鑽Rubyプログラミング β版』まえがき)

研鑽Rubyプログラミング β版www.lambdanote.com

とまぁ、妄想を書きましたが、真面目な(そして実践的な)話に戻ると、この書籍の主張している Deep なモジュールの優位性、そしてそのようなモジュールを実現するために過度のクラス分割を避けるという方針は理解できるものです。あるモジュールがあまりにたくさんのクラスをインタフェースとして外部に公開すると、クライアントの認知負荷は増大します。そのため、モジュールの設計者としては、最小のインタフェースで(少しばかりgeneral purposeな)機能を提供することを考えるのは重要だと思います。

一方で、あるモジュールのインタフェースを固定した上で、そこの内部で(外部に公開されない)クラスやメソッドの分割をどれだけするのかという点については、この節の冒頭に貼ったツイートで自分が書いているように、条件付きでサブタスクの分割を認めていて、納得がいくものです。たとえば、意味のあるまとまりを持ったコードを private メソッドに切り出すことは外部のインタフェースには影響を与えませんが、public メソッドの本体を読もうとしている人にとっては(ライブラリのクラスやモジュール内の他のクラスと同様に)所与のインタフェース、抽象を提供することになり、効果的である場合も多いでしょう(何も考えずに private メソッドに切り出すなよ、はその通り)。

『A Philosophy of Software Design』74ページより

第9章末尾(関数の長さについて)と第12章末尾(コメントについて)の2箇所にわたって、Uncle Bobこと Robert Martin (の、『Clean Code』における主張)が批判されていたのは印象的でした。プロレスですね。

MITアプローチ?

もう一つ、「おっ」と思った点として、以下の一節があります。

it is important for a module to have a simple interface than a simple implementation. (p.61)

(実装もインタフェースもシンプルであるに越したことはないという前提の上で)「シンプルな実装よりも、シンプルなインタフェースを」という主張で、いわゆるMITアプローチの立場を表明しているように読めました。

MITアプローチとNew Jersey アプローチについては、ajitofm 6: Worse is Betterの後半(40分くらいから)で id:t-wada さんが言及していたので、知っている人も多そうです。Richard Gabrielのエッセイ「The Rise of Worse is Better」で「MITアプローチ」のデザイン哲学の一つとして挙げられている「簡潔性」についてのスタンスは、まさにこれです。

Simplicity-the design must be simple, both in implementation and interface. It is more important for the interface to be simple than the implementation.

The Rise of ``Worse is Better''

日本語訳: The Rise of "Worse is Better"

上記のエッセイの中で、MITアプローチは「MIT/Stanford 方式の設計」とも言われていますが、まさにこの書籍の著者はスタンフォード大学の教授なので、(非常に雑な結びつけではありますが)一定のなるほど感がありました。

この書籍のスタンスをMITアプローチ(あるいは大クラス主義)の一形態だと断ずることには実益はないのですが、この書籍以外にもさまざまな立場があり、一部対立するように見える部分がある(例えば、MITアプローチと対置されているNew Jerseyアプローチでは、「実装のシンプルさの方がインタフェースのシンプルさよりも大事だ」と主張しています)ことがわかると、一歩距離をとって書籍を読むことができると思います。この意味で、書籍のタイトルが「A Philosophy」と不定冠詞になっているのは良いなと思いました(『A Pattern Language』の A にこだわるアレグザンダーオタクの感想)。

追記

改めてWorse is Better 関係の記事やツイートを読み直していて気づいたのですが、 Worse is Better についての @rui314 さんの記事で、Stanford在学中に "The Rise of Worse is Better" のオリジナルを読まされたとおっしゃっていて、MIT/Stanfordアプローチ といっても現代にまでどこまで引き継がれているかは相当怪しいということが改めてわかりました。

もともとの「悪いほうが良い」エッセイの最初のバージョンは1989年に書かれた。その中では「良いデザイン」はMITやStanfordのスタイルとして言及されている。面白いことに僕はこのデザイン原則のエッセイをStanfordのコンピュータサイエンスの授業で読まされた。どうやらStanfordの授業もこの30年間ですっかり「悪い方向」に変わってしまったようだ。その授業で僕がクラスの掲示板に投稿した文章を多少修正の上で翻訳したのがこのエッセイである。

note.com

おわりに

以上、『A Philosophy of Software Design』を読んだよ、というお話でした。

なお、日本語翻訳については、柴田芳樹さんが以前ブログの中で、

私が知る限り、残念ながら、この本は日本語へは翻訳されないようです。

『A Philosophy of Software Design』:柴田 芳樹 (Yoshiki Shibata):SSブログ

と述べられていて、「期待できないのかな?」と思っていたのですが、ドイツ語翻訳(2nd Editionベース)は既に出ているので、もしかしたら出るかもしれません。とはいえ、本文170ページ程度の小さな書籍で、英文もわかりやすかったと思いますので、「英語は苦手だけど読めるようになりたいな・・・」と思っている方にはおすすめです。

関連記事等

著者のGoogleでの講演


www.youtube.com

e34.fm のホストの deeeet さんのツイートと記事

deeeet.com

その他ブログなど

https://twitter.com/yohamta/status/1478381746962186240

blog.stanaka.org

budougumi0617.github.io

syfm.hatenablog.com

tech.innovator.jp.net

文化からツールまでを扱ったタイトルに違わぬ大著『Googleのソフトウェアエンジニアリング』を読んだ

昨年11月末に発売された『Googleのソフトウェアエンジニアリング』を読みました。

細かい内容についての感想はTwitterの方に放流しているので、ブログでは簡単に。

全体の構成

書籍全体の構成は、以下のようになっています。 分量としては、「第4部 ツール」が最も大きな部分を占めています。 第2部から第4部について少しずつ感想を書きます。

  • 第1部 主題(p.1 ~ p.30)
    • 1章 ソフトウェアエンジニアリングとは何か
  • 第2部 文化(p.31 ~ p.164)
    • 2章 チームでうまく仕事をするには
    • 3章 知識共有
    • 4章 公正のためのエンジニアリング
    • 5章 チームリーダー入門
    • 6章 スケールするリーダー
    • 7章 エンジニアリング生産性の計測
  • 第3部 プロセス(p.165 ~ p.374)
  • 第4部 ツール(p.375 ~ p.632)
    • 16章 バージョンコントロールとブランチ管理
    • 17章 Code Search
    • 18章 ビルドシステムとビルド哲学
    • 19章 GoogleのコードレビューツールCritique
    • 20章 静的解析
    • 21章 依存関係管理
    • 22章 大規模変更
    • 23章 継続的インテグレーション
    • 24章 継続的デリバリー
    • 25章 サービスとしてのコンピュート
  • 第5部 結論(p.633 ~ p.636)
    • あとがき

「第2部 文化」について

有名な HRT(謙虚、尊敬、信頼) の原則の話から始まり、同僚とのコラボレーションやリーダーシップ、マネジメントの話をしています。

第2章、第5章の執筆担当者はBrian Fitzpatrickで、この方は『Team Geek』の共著者でもあります。内容的にも、HRTに関する部分や、リーダーシップに関する部分などは、『Team Geek』の改訂版とも言える内容になっています。

エンジニア組織の文化の話は自分は関心のある領域で、どの章も面白く読んだのですが、中でも印象的だったのは第4章の「公正のためのエンジニアリング」です。分量としては多くないのですが、Google が(過去の失敗も踏まえつつ)どのようにダイバーシティなどの課題に取り組んでいるのかなどが書かれていて、面白く読みました。日本の企業では Google ほどこの論点についての課題感は強くなりづらいと思いますが、この書籍で丸々一章がこのテーマのために割かれたのは意味のあることだと思います。

「第3部 プロセス」について

スタイルガイド、コードレビュー、ドキュメンテーション、テスト、廃止について取り上げています。Google のテストについては、『テストから見えてくるグーグルのソフトウェア開発』(未読です)という本があるほか、 Google Testing Blog でもアウトプットを見ることができますが、本書ではかなり紙幅を割いて説明がされています。

testing.googleblog.com

第3部で説明されているプロセスは、第4部で説明されるGoogleのツールと結びついている側面が相当あるのですが、第3部は細かいツールの話をしないようにして記述されているので、Google で働いていない人にとっても参考になる内容が多く含まれていると感じました。

「第4部 ツール」について

第4部では、Google のエンジニアリング(特に第3部で説明されているプロセス)を支えるツール(基本的には社内ツールですが、一部オープンソース版のあるものもあります)が説明されています。正直、自分の仕事に直接役立てようと思って読むのは難しいことが多かったですが、どういう考えに基づいてそれらのツールが設計・運用されているかというのは面白く読みました。

ひとつだけ取り上げると、タスクベースのビルドツールとアーティファクトベースのビルドツールの話は面白かったです。Maven や Rake といった従来のビルドツールは、大多数がタスクベースで、タスクベースであるがための課題を抱えており、それらの課題をどのようにBlaze(そのオープンソース版がBazel)などのアーティファクトベースのビルドツールが解決していくのか、ということが分かりやすく説明されています。Bazel を使ってみたくなりました。

bazel.build

おわりに

Googleのソフトウェアエンジニアリング』、全部で600頁超の大著ですが、細かく章立てされているので、少しずつ読み進めるのには適した書籍だと思います。また、章ごとに執筆担当者の違う書籍にありがちな全体のつながりの悪さはそこまでなく、部という単位ではかなりまとまりを感じました。

かなり幅広いテーマについて一定程度の深さで話をしている書籍ですので、これからは広く参照されていくことになりそうだなと思いました。自分も一回では到底消化しきれていないので、これから折に触れて手に取ろうと思います。

f:id:ky_yk_d:20220103182106j:plain

Technical leadership and glue work / Being Glue を読んで

Tanya Reilly による「Technical leadership and glue work」という講演(および、その文字起こしによるブログ「Being Glue」)があります。(以下、講演に特に言及する場合を除き、「記事」として言及します)。


www.youtube.com

noidea.dog

Manager ではなく Individual Contributor としてのキャリア

筆者の Tanya Reilly は、元GoogleのStaff Systems Engineerで、現在はSquarespaceでPrincipal Software Engineerを務めています。これらの職名からもわかるように、彼女はマネージャーではなくエンジニアとして昇進を続けながら活躍してきた人です。

エンジニアリングマネージャーについての書籍は、翻訳が出ている『エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド』(原題:The Manager's Path)や『フェイスブック流 最強の上司』(原題:The Making of a Manager)の他にも、『An Elegant Puzzle: Systems of Engineering Management (English Edition)』などの書籍がありますが、IC(Individual Contributor)の上位職のための書籍としては『Staff Engineer: Leadership beyond the management track (English Edition)』があるくらいで、まだ整備されていないという状況があります(これは、ICの上位職の責務が企業により非常に異なっているという事情もあるようです)。

Tanya Reilly は、このICの上位職のための書籍を目下準備中(発売予定は2022年10月。Oreillyのサブスクで Early Release 版の第1章まで読めます)なのですが、冒頭の記事も近接した問題系についてのものです( Tanya Reilly が書籍で挙げているサンプルのキャリアラダーでは、この記事で言及される Senior Engineer の上で Staff Enginner と Manager とに分岐するのですが)。

learning.oreilly.com

(2024/3/5追記、すでに『The Staff Engineer's Path』として発売されています。)

Glue Work とその危険性

この記事の主題である「Glue Work」とは、他のメンバーがブロックされているのを助けたり、設計ドキュメントをレビューしたり、新しいメンバーのオンボーディングをしたりという、一見すると「技術的」ではないと思われるような仕事です。著者によると、これらの仕事は「技術的なリーダーシップ」の一部であり、シニア開発者には求められるものである一方で、シニアになる前にこれらの仕事をしすぎることはキャリアをダメにしてしまう危険性があるとされています。なぜなら、これらの仕事をしすぎると、コーディングなどのより「技術的」な仕事に時間を割くことができず、「シニア」への昇進で求められるような「技術的」スキルを磨く機会を失ってしまうからです。

記事の中では、1人の女性エンジニア(ここでわざわざ「女性」というのには意味があり、記事の後半で女性が男性よりも多くこの種の昇進に結びつかない仕事を頼まれる/する傾向があるという話が紹介されています)のストーリーを用いて説明がなされますが、この話を「自分のことだ!」と思う人は少なくないようです。自分も、割合この種の仕事をしがち(好んでやっているし、自分だけがしているわけでもないので不満はないのですが)なので、読んでいて「あーわかる〜」となる部分が多くありました。

自分は何をすべきで、何をすべきじゃないんだろう

記事の紹介はここまでで、ここからは自分の話なのですが、自分は結構な割合の労働時間を Glue Work に時間を割いている時期が今まで多かったです。コーディングが嫌いなわけではないし、技術に興味がないわけでもないのですが、どちらかというとコーディング以外の形でプロジェクトやチームに貢献するという機会の方を選択してきたように思います。

そうしてきたのは(後ろ向きな理由もなかったわけではないですが)、それが一番自分がその時点で貢献できるからであったり、それが一番面白いと思ったからであったりするのですが、改めて立ち止まってみると、自分のキャリアにとっては好ましくない部分もあったのかなと思いました(よかったと思う部分も多々あります)。たとえば、会社の身の回りのエンジニアに比べて、手が動くまでが遅いというのは、エンジニアとしての自分の大きな欠点だなと思っているところなのですが、 これが改善されてきていないのは自分のこれまでの選択の産物に他ならないと思います。

プログラミング経験ゼロからこの業界に入ってそろそろ5年になりますが、ちょうど自分が業界に入ったあとに「エンジニアリングマネージャー」というトピックが日本でもポピュラーになり、「将来はEMとかそっち方面かなー」とずっと思ってきたので、コーディングなど「技術的」な仕事に多くの時間を割くということをそこまで重んじてこなかったという側面もあります(現場の開発者としての経験はEMにも重要だと考えて、現場に近い仕事を転職の時に選ぶことはしましたが)。

Glue Work についての記事は、自分のキャリアについて特定の方向の示唆を与えるものでもないのですが、改めて自分のキャリアというものを考えてみたときに、どういう仕事を日々選択してやるのかというところも重要になってくるな、というのを改めて思わされました。自分のキャリアの観点とは別に、チームの状況という観点からも、これまでと同じ動き方をしていくことがベストではないのではないかというのが最近思い始めていることなので、改めて自分の働き方、動き方について、チームのメンバーやマネージャー、あるいは社外の人たちと話し合ってみたいなと思いました。

e34.fm

iki-iki のご紹介:いきいき Advent Calendar 2021

本記事は「いきいき Advent Calendar 2021」の18日目の記事です。

t.co

昨年の半ばごろから、 iki-iki という活動(?)に参加しています。この記事ではこのiki-ikiを紹介します。

scrapbox.io

iki-iki ってなに

iki-iki とは、以下のようなものです。

ここはいきいきマニフェスト(仮) に心を動かされた人びとの活動の場です。

WelcomeVisitors - iki-iki

iki-iki では、Discordで雑談したり、Scrapboxを育てたりしています。 Scrapbox内の記事としては、 @kakutani が書いた『ユニコーン企業のひみつ』あとがきや、QRCチームトポロジーの記事を見たことがある人がいるかもしれません。

scrapbox.io

scrapbox.io

iki-iki の歴史

iki-iki の歴史は、@kkd の書いた以下の記事に触発された @kakutaniが「ノリで」Discordサーバを作ったところから始まっています。

note.com

f:id:ky_yk_d:20211206214328p:plain

しかし、お二人が「いきいき」と言い出したのは最近ではなく、どうやら2008年ごろに遡れるようです。 @kkd が2008年夏に「沢田マンション」を訪れて、そこから「いきいき」というフレーズが盛り上がっていったようです。 @kkd 自身は、アレグザンダーの「無名の質」や「生命構造」にも強く影響を受けていると書いています。

giantech.jp

scrapbox.io

2009年時点で既にWikiWikiWebと「いきいき」とを結びつける発言を @kakutani がしていて、10年以上経って実際にWiki(実装としてのScrapbox)が立ち上がったというわけです。

iki-iki では執筆者を募集しています

以上、iki-ikiの紹介でした。

iki-iki の執筆を一緒にやってくれる人をいつでも募集しています。 以下のページを参考に中の人にお声がけください!

scrapbox.io

『Release It!』の次に読みたい(読むとは言ってない)英語の技術書

最近、英語の勉強を改めてしていて、その一環として少しずつ読んでいた『Release It!』の2版を一周しました。

英語の本を読むのは続けていきたいと思っているのですが、日本語の本ほどのスピードではまだ全然読めないので、「これ!」という少数の本を読んでいく方針で当面は進めようと思っています(せっかくオライリーのサブスクを契約しているので、たくさんの本を拾い読みするというのもアリなのですが)。

そこで、次に読む本を考えていくにあたって、せっかくなので候補に挙がっている書籍をリストアップしておきます。

「これは翻訳の予定があるよ」というものはこっそり教えてください(無茶言うな)

Dynamic Reteaming

『チームトポロジー』でしばしば言及されていた本。

オライリーのサブスクでオーディオブックを少しずつ聴いている限りでは、事例が結構厚めな印象を持っている。固有名詞の入っているところばかり耳に残っているだけという説もありますが・・・

I. What Is Dynamic Reteaming?
1. The Evolution Of Teams
2. Understanding Teams
3. The Power Of Team Assignment
4. Reduce Risk And Encourage Sustainability
II. Dynamic Reteaming Patterns
5. One-By-One Pattern
6. Grow-And-Split Pattern
7. Isolation Pattern
8. Merging Pattern
9. Switching Pattern
10. Anti-Patterns
III. Tactics For Mastering Dynamic Reteaming
11. Adapt Your Organization For Dynamic Reteaming
12. Plan Your Dynamic Reteaming Initiative
13. After Dynamic Reteaming: Transitions And Team Calibrations
14. Reflect And Determine How To Shift
IV. Conclusion

永瀬美穂さんが翻訳してくれるのに期待している 👀

オライリーサブスクでも読める。

Dynamic Reteaming, 2nd Edition [Book]

Learning Domain-Driven Design

2021年11月に出たばかりのドメイン駆動設計に関する本。

オライリーサブスクで読める↓のレポートがよくまとまっていると評判なので、この書籍も期待できそう。目次を見た感じも良さそう。

www.oreilly.com

I. Strategic Design
1. Analyzing Business Domains
2. Discovering Domain Knowledge
3. Managing Domain Complexity
4. Integrating Bounded Contexts
II. Tactical Design
5. Implementing Simple Business Logic
6. Tackling Complex Business Logic
7. Modeling The Dimension Of Time
8. Architectural Patterns
9. Communication Patterns
III. Applying Domain-Driven Design In Practice
10. Design Heuristics
11. Evolving Design Decisions
12. EventStorming
13. Domain-Driven Design In The Real World
IV. Relationships To Other Methodologies And Patterns
14. Microservices
15. Event-Driven Architecture
16. Data Mesh

オライリーサブスクでも読める。

Learning Domain-Driven Design [Book]

Building Microservices

『マイクロサービスアーキテクチャ』の第二版。既に翻訳が進んでいそうな気がする。初版に比べてかなり分厚くなっているので大変そうですが・・・

オライリーサブスクでも読める。

Building Microservices, 2nd Edition [Book]

Software Architecture: The Hard Parts

kawasimaさんが読んでいるのを見て面白そうだなと思っている本。

1. What Happens When There Are No “Best Practices”?
I. Pulling Things Apart
2. Discerning Coupling In Software Architecture
3. Architectural Modularity
4. Architectural Decomposition
5. Component-Based Decomposition Patterns
6. Pulling Apart Operational Data
7. Service Granularity
II. Putting Things Back Together
8. Reuse Patterns
9. Data Ownership And Distributed Transactions
10. Distributed Data Access
11. Managing Distributed Workflows
12. Transactional Sagas
13. Contracts
14. Managing Analytical Data
15. Build Your Own Trade-Off Analysis

ほぼ同じ執筆陣のこちらの方を先に読んだ方が良い説もある。

2022/08/19 追記:翻訳が出ています。

www.oreilly.co.jp

Chapter 1: Introduction
Chapter 2: Architectural Thinking
Chapter 3: Modularity
Chapter 4: Architecture Characteristics Defined
Chapter 5: Identifying Architecture Characteristics
Chapter 6: Measuring and Governing Architecture Characteristics
Chapter 7: Scope of Architecture Characteristics
Chapter 8: Component-Based Thinking
Chapter 9: Architecture Styles
Chapter 10: Layered Architecture Style
Chapter 11: Pipeline Architecture
Chapter 12: Microkernel Architecture
Chapter 13: Service-Based Architecture
Chapter 14: Event-Driven Architecture Style
Chapter 15: Space-Based Architecture
Chapter 16: Orchestration-Driven Service-Oriented Architecture
Chapter 17: Microservices Architecture
Chapter 18: Choosing the Appropriate Architecture Style
Chapter 19: Architecture Decisions
Chapter 20: Analyzing Architecture Risk
Chapter 21: Diagramming and Presenting Architecture
Chapter 22: Making Teams Effective
Chapter 23: Negotiation and Leadership Skills
Chapter 24: Developing a Career Path

いずれもオライリーサブスクでも読める。

Software Architecture: The Hard Parts [Book]

Fundamentals of Software Architecture [Book]

Strategic Monoliths and Microservices

『実践ドメイン駆動設計』の Vaughn Vernon の最新刊。

イベント駆動やCQRSなど技術的な側面と、ビジネスの側面との両面にバランスよく触れられていそうな印象。

Part I: Transformational Strategic Learning through Experimentation
Chapter 1: Business Goals and Digital Transformation
Chapter 2: Essential Strategic Learning Tools
Chapter 3: Events-First Experimentation and Discovery
Part II: Driving Business Innovation
Chapter 4: Reaching Domain-Driven Results
Chapter 5: Contextual Expertise
Chapter 6: Mapping, Failing, and Succeeding—Choose Two
Chapter 7: Modeling Domain Concepts
Part III: Events-First Architecture
Chapter 8: Foundation Architecture
Chapter 9: Message- and Event-Driven Architectures
Part IV: The Two Paths for Purposeful Architecture
Chapter 10: Building Monoliths Like You Mean It
Chapter 11: Monolith to Microservices Like a Boss
Chapter 12: Require Balance, Demand Strategy

オライリーサブスクでも読める。

Strategic Monoliths and Microservices: Driving Innovation Using Purposeful Architecture [Book]

Modern Software Engineering: Doing What Works to Build Better Software Faster

『継続的デリバリー』の David Farley の新刊。彼の YouTube はときどき見ている。


www.youtube.com

Part I What Is Software Engineering?
1 Introduction
2 What Is Engineering?
3 Fundamentals of an Engineering Approach
Part II Optimize For Learning
4 Working Iteratively
5 Feedback
6 Incrementalism
7 Empiricism
8 Being Experimental
Part III Optimize For Managing Complexity
9 Modularity
10 Cohesion
11 Separation of Concerns
12 Information Hiding and Abstraction
13 Managing Coupling
Part IV Tools To Support Engineering In Software
14 The Tools of an Engineering Discipline
15 The Modern Software Engineer

オライリーサブスクでも読める。

Modern Software Engineering: Doing What Works to Build Better Software Faster [Book]

Building Secure and Reliable Systems

Amazonの「一緒に購入されている本」で見つけたもの。

Google の SRE本シリーズの第三弾。

目次を見た感じ、テーマが多いので個々の掘り下げはそこまでなのかな?という気がするけど、『Release It!』と近い感じで一読しておいて損はなさそう。

I. Introductory Material
1. The Intersection Of Security And Reliability
2. Understanding Adversaries
II. Designing Systems
3. Case Study: Safe Proxies
4. Design Tradeoffs
5. Design For Least Privilege
6. Design For Understandability
7. Design For A Changing Landscape
8. Design For Resilience
9. Design For Recovery
10. Mitigating Denial-Of-Service Attacks
III. Implementing Systems
11. Case Study: Designing, Implementing, And Maintaining A Publicly Trusted CA
12. Writing Code
13. Testing Code
14. Deploying Code
15. Investigating Systems
IV. Maintaining Systems
16. Disaster Planning
17. Crisis Management
18. Recovery And Aftermath
V. Organization And Culture
19. Case Study: Chrome Security Team
20. Understanding Roles And Responsibilities
21. Building A Culture Of Security And Reliability

オライリーサブスクでも読める。

Building Secure and Reliable Systems [Book]

おまけ: Brutal Refactoring

『レガシーコード改善ガイド』の Michael Feathers の幻の新刊(?)。

発売予定が示されてから発売が遅れに遅れ、今月発売予定になっているのだが、著者のTwitterなどでも全く情報が出てきておらず、本当に出るのかいまだに謎でした。

しかし、↓のインタビューの記録を読むと、これはどうも出版はされないようです。『レガシーコード改善ガイド』にはお世話になっているので楽しみだったのですが・・・

www.infoq.com

It feels like a whack-a-mole type thing because that is not a real book. I gave a workshop on that in Chicago. I forgot how many years ago, but somebody has put that up as a page on Amazon and I need to go and figure out where to go and get that taken down.