分散システムのバリエーションとトレードオフを掘り下げる

本書は『ソフトウェアアーキテクチャの基礎 ―― エンジニアリングに基づく体系的アプローチ』の続編にあたる書籍である。著者は前著の著者陣と新たに加わった2名の計4名。前著は「〜の基礎」というだけあって、概論からソフトスキルまで含む入門編のような位置づけだったが、そちらと比較すると本書は応用編と言える。

タイトルに含まれる「ハード」という言葉は、「難しい」という意味に加え、「堅い＝変更するのが大変」という意味が込められている。つまり前著より難しいところに踏み込むわけで、いささかの手応えは感じるかもしれない。もっとも、読み手としてはとても気になるところを掘り下げてくれているため、前著は下準備で本書が本番、という趣きもある。ある程度ソフトウェアアーキテクチャに知識がある人であれば、前著は飛ばして本書から読み始めてもよいかもしれない。ただし本書で比較されるアーキテクチャのバリエーションは前著第II部で詳説されているものなので、適宜参照した方が理解は進みそうである。

また、今回は「Sysops Squadサーガ」という架空のサービスの事例が随所に登場する。ここではサービスに生じた課題とそれを解決するアーキテクチャの検討が、物語の対話形式で具体的に語られており、取り扱う題材がハードなものであっても、親しみやすくなるよう工夫されている。

本書のサブタイトルである「分散アーキテクチャのためのトレードオフ分析」にある通り、本書は分散アーキテクチャが論点の中心となる。とはいえ、最近流行のマイクロサービスやイベント駆動アーキテクチャを称賛したり、その導入方法を解説したりする、といった類の書籍ではない。本書のポイントはサブタイトルの後半にもなっている「トレードオフ分析」である。

本書第1章の章タイトルは「『ベストプラクティス』がないとどうなる？」である。この章タイトルの通り、本書のスタンスは、「分散アーキテクチャにはベストなアーキテクチャというものはなく、全てはトレードオフである」というものだ。つまりどんなアーキテクチャにもメリットとデメリットがあり、それと現在の状況や環境を元に最悪（ワースト）ではない選択肢を選ぶことがアーキテクトの役割であるとされる。

本書は2部構成になる。前半である第I部「分解する」では、アーキテクチャの分解、データの分解、サービスの分解について語られる。明確な構造が崩れてしまって混沌としたソフトウェアは「巨大な泥団子」とも言われるが、このようなソフトウェアには分散アーキテクチャ以前に、まず適切な粒度に分解し構造を整理しなければならない。それを怠って分散アーキテクチャを導入すると「分散した巨大な泥団子」になる、という厳しい現実が語られる。

これを回避するため、コードやデータを分解した上で、最終的にはサービスとして分解するのだが、このサービスをどう分解するかも難しい。分散アーキテクチャのさまざまなバリエーションに加えて、サービスの粒度をどうするかという問題については、粒度分解要因と粒度統合要因が紹介される。つまり、サービスを分解したくなる要因があると同時に、サービスを統合したくなる要因もあるのだ。まさにトレードオフである。

もちろん、分解された各サービスは何かしらの方法で通信し連携しあう必要がある。そちらは後半である第II部「つなぎあわせる」でさらに細かく解説されるのだが、各章で語られる分散処理、とりわけエラーが起きた際のリカバリ方法（の難しさ）についての解説を読むと、分散アーキテクチャのしんどさがしみじみと伝わってくる。さすがのハードパーツとも言えるが、それでもさまざまな分類やそれぞれのメリット・デメリットが分かるだけでも、アーキテクチャを決定する際の心強い援軍として役立つだろう。

分散アーキテクチャに興味のある方、悩んでいる方なら、前著に引き続き、読んでおきたい一冊である。

自動テストの時代に、ソフトウェア開発を駆動するための設計技術

本書はケント・ベックによるテスト駆動開発（TDD）の古典とも言える『Test Driven Development: By Example』を、2017年に新たに翻訳し直し、新装版として復刊した本である。

再刊にあたっては、JavaのコードをJUnit 5、PythonのコードをPython3で書き直したり、本文中のサンプルコードを増やして読みやすくする等の独自の工夫が加えられている（本書「訳者あとがき」より）。2020年代に読むには原著よりもおススメかもしれない。

本書は3部構成になっており、複数国の通貨を扱うコードを題材にテスト駆動開発を実践していく第1部、テスティングフレームワークを自作しながら（！）そのしくみを解説する第2部、これまでの復習も兼ねつつ、テストで使われるパターンや方法を挙げていく第3部、そして訳者により書き下ろされた「付録C　訳者解説：テスト駆動開発の現在」を含めた3つの付録からなる。

原著の刊行から20年ほど経った現在、テストの自動化を取り巻く環境は大きく変わった。CI/CDはめずらしいものではなくなり、ソフトウェアのフレームワークにはテストを実行するしくみをあらかじめ持っているものも少なくない。日常的に開発をしながらテストを書き、自動で実行させるための土台は大幅に改良されて久しい。その意味では、とりわけテスティングフレームワークを自作する第2部は、最初は軽く読み流して、既存のxUnitツールを使えばよいかもしれない。

しかしながら、TDDが一般的になっているとは言えない。「テストを自動で実行できる・していること」と「開発をテストで駆動すること」には大きな違いがある。いわゆるリグレッションテスト（回帰テスト）、つまりコードの挙動が変わっていないかを知るためのテストコードを、プロダクションのコードを書くよりちょっとだけ早く書くだけでは、本書が目指した「テスト駆動開発」とは言えないのではないか？……このあたりのテストの受容や意味の希薄化・形骸化について、もっとも網羅的で入手しやすい日本語の文献は、本書の「付録C」だと言っても過言ではない。この付録Cだけでも本書を読む価値はあるのではないか。

では、今あらためて「テスト駆動開発」とはどのようなものなのかを知るにはどうすればよいか。そのためにおすすめしたいのが本書の第1章である。ケントがコードを前に、あれやこれやと考えながらコードを書いたり消したりしていく、その試行錯誤からは、まさしくテストによって開発が駆動されていく様子が力強く伝わってくるはずだ。

本書の翻訳を行ったt-wadaさんこと和田卓人氏はTDDの第一人者として知られている。そのきっかけとなったのも本書であり、大変な開発現場に放り込まれて帰る途中の深夜バスの中で本書を写経しながらTDDをマスターしたという逸話もよく知られている。あのt-wadaさんにもそんな時代があったのか……という不思議な感慨も覚えるが、それからTDDの布教に励み、一時期は翻訳書が品切れで入手困難になっていたことを嘆いていた氏が、ついに本書の翻訳を手掛け、新装版として復活させたことは慶賀に堪えない。

テストコードをこれから書き始めたい人はもちろん、テストを書いてはいるけれど今ひとつしっくりこない、という人にも、改めて本書を勧めたい。

2022/12/26