O'Reillyサブスクリプションで読むことができる今年発行された書籍の中から、これは良いんじゃないかな、と感じたものを紹介します。
Balancing Coupling in Software Design
『[ドメイン駆動設計をはじめよう』原著者のVlad Khononovさんの最新作で、ソフトウェアにおいて結合とは何かを一冊まるまる使って掘り下げた本です。
ソフトウェアにおける結合というと、その指標として50年以上前に提唱された構造化設計時代の結合強度が用いられがちです。本書ではこれについて解説をしつつも、新たな現代における結合強度の基準を提案しています。(元ネタはMichael NygardのUncouplingを統合したものでもあるのですが…)
それから開発の辛みは結合強度だけでなく、「距離」「変動性」も影響してくるため、これらのバランスをとるのが重要であるといい、以下公式を導き出します。
BALANCE = (STRENGTH XOR DISTANCE) OR NOT VOLATILITY
この公式を使って、既存の「良い」とされる設計プラクティスがいかにしてバランスを取っているかの説明は見事なので、ぜひ読んでみてください。
本書での主張の概要は、Khononovさんの講演資料や動画でも見ることができます。
"Looks Good To Me"
プルリクベースのレビューをいかにして上手くやるか。これまでありそうでなかったテーマについて書かれた本です。良いプルリクの書き方、良いレビューコメントの書き方なども丁寧に説明されていて参考になります。
ありがちなレビューのアンチパターン(プルリクがデカい、意地悪なレビューコメントなど)についても、どう対処したら良いかも丁寧に解説してあります。
コードレビューに関して悩んでいる方には、まずこの一冊を薦める的な書籍だと思います。
Facillitating Software Architecture
ファシリテーティングと銘打っているものの、ADR(Architecture Decision Records)のシングルテーマで書かれた本です。
意思決定は詳細プロセスに分割できて、特に
- 代替案を作る(Decision made)
- 代替案から1つを選択する(Decision taken)
を区別しよう、というアイデアはなるほど、と思いました。
現代主流をなす分散化された小さな開発チームでは、中央集権的なアーキテクトチームなんてものは作らずに、各チームが意思決定を行います。それでアジリティは向上できても、アーキテクチャ的負債を多く抱えてしまうケースも増えます。「代替案から1つを選択する」フェーズは各チームが主体となりアカウンタビリティを持つものの、「代替案を作る」フェーズはチームの外の有識者にも積極的に意見を求めながら実施しようということで、アジリティとアーキテクチャ的負債のバランスをとろうというのが本書の主張です。そのようなプロセスをアーキテクチャ助言プロセスと呼んでいます。
この助言プロセスを円滑に回すためにADRを活用しようということです。
Continuous Deployment
これまでContinuous Deploymentについては、幾つかの書籍で言及されてはいたものの、あまり詳細には書かれてきませんでした。本書ではContinuous Deploymentを実現した世界はどういうものかをリアリティを持って見せてくれます。
Continuous DeploymentはContinuous Deliveryと混同されがちなところもあり、一般的に語られているそれらの違いも、本番環境へのデプロイに人による承認行為を挟むかどうかの点しかありません。(Atlassianの解説参照)
ですが、その僅かな違いが大きな効果を生みます。継続的デプロイメントではすべてのソースコミットが自動的に本番環境に運ばれることを意味するので、実運用上、そのまま変更がユーザに影響を与えることがないように隠しておくことが原則になります。その隠すための代表手段がフィーチャートグルです。
- フィーチャートグルを利用し変更を隠した状態でデプロイする
- フィーチャートグルをQA担当者にだけONにして、本番環境でテストする
- ビジネスサイドの良きタイミングで、フィーチャーフラグをConsumerに向けてONにして、それらの変更機能が使えるようにする
つまりデプロイとリリース(Consumerが機能を使えるようにすること)が全く別の作業になるわけです。これには大いなるメリットがあります。
- 本番リリース作業を開発者がやる必要も、立ち会う必要もない
- 本番相当のテスト環境を準備・維持する必要がない
もちろん、この実現には大いなる難しさも伴います。
- データベースのマイグレーションを伴うフィーチャートグルをどう設計しデプロイすると安全か?
- 本番でテストすると業務データが汚れてしまうが、それをどう扱うか?
『Continuous Deployment』では、これらの難しさに対しても具体例を交えながら、一応の答えを用意してあります。Continuous Deploymentによって得られるメリットと増える開発難度を天秤にかける必要があり、現段階ではメリットが上回るのは難しそうという個人的感覚を私は持っています。が、開発難度は技術の進歩によって徐々に下がっていくことが予想されるので、今このタイミングでContinuous Deploymentについて正しく認識しておくのは決して無駄にはならないのではないか、とも思います。
Architecture Modernization
モダナイゼーションがテーマであるものの、それは話のきっかけに過ぎず、ヨーロッパ圏でのソフトウェア設計コミュニティでよく扱われているテーマを幅広く扱っています(そしてそれら1つ1つも決して浅い内容ではない)。
- (現代的)ドメイン駆動設計
- EventStorming
- チームトポロジー
- Wardley Mapping
- 内部開発者プラットフォーム(IDP)
特に、ドメイン駆動設計に関してのドメイン境界の見つけ方は、私の知る限り最も体系だった説明がされている書籍なので、そこを読むだけでも価値があると思います。
なお著者のNick Tuneさんは『Patterns, Principles, and Practices of Domain-Driven Design』というドメイン駆動設計関連本の中で最も分量の多い書籍にも携わっています。
Becoming SRE
既に日本語訳も出ています。『SREをはじめよう』
近年、SREに関する書籍は何冊か出ているので内容自体は、目新しいものはない
特に10章「失敗から学ぶ」はポストモーテムについて説明されていますが、何かと間違った運用がされがちな5Whys(なぜなぜ分析)の陥りがちな罠について解説されていて、ここだけでもできるだけ多くの方々に読んでほしいところです(同じ誤解を解くという点では、Atlassianの5つのWhyの擁護も合わせて読むと良いです)。
Acing the System Design Interview
その名の通り、技術面接対策の体で書かれた本なのですが、各例題の質が良くて、ソフトウェアアーキテクチャについて検討すべき観点と代替案にとてもリアリティがあり勉強になります。
ベンダーの影響が強い現場では、ソリューション主導でのアーキテクチャ選定になりがちですが、本書は非機能要求から、必要なソリューションを導き出すという本来のアーキテクチャ設計の進め方を何パターンもロールプレイできる稀有な書籍なので必読です。
Taming Your Dragon: Addressing Your Technical Debt
「技術的負債にどう立ち向かうか」のシングルテーマで書かれた本です。よくSNS上でも激論が交わされるように、技術的負債というアナロジーは破綻があるところもあり、より精緻にモデル化する必要がある、ということで本書ではオニオンモデルなるものを提唱しています。
本書だけでは、技術的負債のアナロジーの破綻や実際の構造が分かったから何なんだ、という感想を持つことになると気がしますが、より解像度を高めた議論の足場にはなるんじゃないかと思います。
Collaborative Software Design
EventStormingのような、いろんな人を巻き込んでモデリングセッションをやってみた方は、実感したことがあるかもしれません。大人数でモデリングするメリットはもちろんあれど、全員のコントリビューションレベルは同じではなく、もっと効果的なものにできるはずだけどな…、と。
本書はそのような協働モデリング(EventStorminに限らない)の場で、起こりがちな現象と原因をこれでもかと盛り込んで解説し、解決策をあれこれ示しています。
これは、協働モデリングを取り入れている現場では、必読の一冊と言えます。
Productive Failure
O’Reillyサブスクには技術書ではないもの(学術書やビジネス書のようなもの)も多く登録されていて、今年は技術書と同じ分量くらいはそういう本を読んでみました。
その中から特に興味深かった本として『Productive Failure』を挙げておきます。
一般的な学校教育は直接指導と呼ばれる、先ず教えて、それから問題を解かせるという形式を取ります。一方でProductive Failureはこれを逆転し、先ず問題を解かせて、その後指導を行うことをやります。問題の性質にもよるが、より学習効果が高まる研究があるとのことです。
当然ながら問題の設計が重要で、学習対象者が手も足もでないような難度の問題では効果が得られません。ということで本書後半では、効果の高い問題設計をどう行うかが説明されています。
ソフトウェア技術者育成に関しても、大いに参考になりそうな一冊です。
技術書大賞
今年出たものの中から1冊だけ選ぶとしたら『Balancing Coupling in Software Design』です
。ソフトウェアの結合度や複雑さの話を持ち出すのに、何十年も前の文献を引っ張ってこなくてはならなかったものを、Balancing Couplingが変えてくれるのではないかと期待しています。
次点を挙げるとすれば、『Continuous Deployment』『Acing the System Design Interview』『Collaboration Software Design』でしょうか。
来年も良い技術書がたくさん出版されることを期待しています。