あの有名 OSS のコードは、この本の影響を受けている

この記事は約 6 分で読めます。

OSS の設計思想はどこから来るのか

先に結論を書きます。用語ごと辿れる影響関係は 3 系統です。GoF のデザインパターン、UNIX 哲学、そしてリファクタリングの「コードの臭い」。この 3 つは名前が OSS やツールの中に残っているので、コードを読むだけで出どころが分かります。それ以外の「この設計はあの本の影響だ」という話は、作者本人の言及が見つかるかどうかで扱いを変えるべきです。

React、Rails、Linux カーネル、Git。これらの OSS を使っていると、設計の随所に「なぜこうなっているのか」と疑問に思う箇所があります。

その答えの一部は、技術書の中にあります。設計判断の背景を、コミットログや設計ドキュメント、カンファレンスの発表で本の名前を挙げて説明する作者もいます。ただし、構造が似ているだけで直接の影響が確認できない例も多く、外から見て断定はできません。

設計パターンと OSS の関係

GoF のデザインパターンは、無数の OSS に影響を与えています。

Observer パターンは、Node.js のイベントエミッターに見られます。公式ドキュメントの説明どおり、Node.js の中核 API は emitter が名前付きのイベントを発行し、登録した listener 関数が呼ばれる構造で組まれています。React 側で同じ形をしているのは、コンポーネントの内部状態そのものではなく、外部ストアを購読する仕組みです。

Strategy パターンは、認証ライブラリの Passport が名前ごと採用しています。認証方式ごとに差し替えられる strategy を別パッケージとして切り出す構造で、公式ドキュメントも認証方式の種類だけ strategy があると説明しています。Factory パターンは、DI コンテナや ORM のモデル生成に使われています。

ここに 1 つ落とし穴があります。Web フレームワークのミドルウェアを Strategy パターンと説明した記事をときどき見かけますが、あれは要求を順番に次へ渡していく連鎖の形なので、当てはめるなら Chain of Responsibility です。パターン名は「差し替えられる」「連鎖する」といった構造の違いで決まるもので、見た目の似ている実装に別のパターン名を貼ってしまいやすい。

デザインパターンの本を読んでから OSS のコードを読むと、「ああ、ここは Observer パターンだ」と構造が見えるようになります。逆に、OSS のコードを読んでからデザインパターンの本を読むと、「あのコードはこのパターンだったのか」と腑に落ちます。

デザインパターンの本を読んだ後に、普段使っているフレームワークのソースコードを覗いてみてください。パターンの実例が見つかるはずです。

UNIX 哲学と CLI ツール

「1 つのことをうまくやれ」「テキストストリームを共通インターフェースにせよ」。UNIX 哲学として語られてきた原則は、現代の CLI ツールにも脈々と受け継がれています。

grep、sed、awk はもちろん、jq、ripgrep、fd といった現代のツールも、パイプで連結して使うことを前提に設計されています。

ただし影響の向きには注意が必要です。この原則を最初に言語化したのは書籍ではなく、UNIX を作った開発者たち自身でした。実装しながら要約された原則が先にあり、書籍はそれを後から体系化して広めました。「本を読んだ作者が UNIX 風に作った」というより、「UNIX の実践から抽出された原則が、本を経由して次の世代のツールへ渡った」と見る方が順序に合います。

UNIX 哲学を扱った本を読むと、「なぜ Linux のコマンドはこういう設計なのか」が理解でき、自分が CLI ツールを作るときの指針にもなります。

クリーンアーキテクチャと、影響関係の検算

Robert C. Martin がクリーンアーキテクチャとして整理した考え方は、ドメインロジックをフレームワークから独立させる、依存の方向を内側に向ける、インターフェースで境界を定義する、という原則にまとめられます。同じ形のレイヤー分けは、多くの Web フレームワークのサンプル構成に見られます。

ただし、似た構成を見つけるたびに「この本の影響」と説明すると取り違えます。クリーンアーキテクチャの名前で原則が整理されたのは 2012 年です。一方 Spring は、初期の J2EE 仕様の複雑さへの反応として 2003 年に生まれたと公式リファレンスが書いています。Spring のレイヤー分けをクリーンアーキテクチャの影響として説明すると、時間の順序が逆になります。

この検算は、どの影響関係にも使えます。本が出た年と、その OSS が問題の構造を採用した年を並べる。順序が合わないなら、影響ではなく、同じ問題に別々に到達した結果か、両者に共通の元ネタがあると考えた方が妥当です。

リファクタリングとコード品質ツール

この系統は、用語そのものが本から出ていると辿れます。「コードの臭い」という言い方は、Kent Beck が Martin Fowler のリファクタリングの本の執筆を手伝っていたときに作った言葉だと、Fowler 自身が説明しています。長すぎるメソッドは、その本が挙げた分かりやすい例の 1 つです。

ESLint のルール、SonarQube の品質指標、IDE のリファクタリング機能。これらが指摘する対象は、本が並べた臭いの一覧と重なる部分が多い。ただしツールが本のカタログをそのまま実装しているわけではありません。ツール側で足された規則もあり、本に載っていても機械では判定できない項目もあります。

ツールが「この関数は長すぎます」と警告するとき、判定しているのは行数のしきい値です。本が問題にしていたのは長さそのものではなく、名前を付けられる単位に分けられていないことでした。しきい値を満たすためだけの分割では、臭いは消えません。

本を読んでから OSS を読む、OSS を読んでから本を読む

この 2 つの順序は、どちらも有効です。

本 → OSS

本で原則やパターンを学んでから OSS のコードを読むと、設計の意図が読み取れます。「なぜこの抽象化があるのか」「なぜこの依存関係になっているのか」が、原則に照らして理解できます。

OSS → 本

普段使っている OSS のコードを読んで「なぜこうなっているのか」と疑問を持ってから本を読むと、本の内容が具体的な実例と結びつきます。抽象的な原則が、目の前のコードという具体例を得て、深く理解できます。

自分が使っている OSS の「影響元」を調べる方法

1. OSS の README や CONTRIBUTING.md に「Inspired by」「References」のセクションがないか確認する
2. 作者のブログやカンファレンス発表で、影響を受けた本に言及していないか検索する
3. OSS の設計ドキュメント (ADR: Architecture Decision Records) に参考文献が載っていないか確認する
4. 見つけた言及と、その OSS が該当の設計を採用した時期を照合する。本の刊行が後なら影響とは呼べない

これらの情報源で裏が取れた範囲に限って、その OSS の設計思想の「元ネタ」となった本を特定できます。裏が取れなければ、似ているという観察までに留めておくのが安全です。

関連記事

• コードを「書く力」と「読む力」は別物 - 読解力を鍛える技術書の使い方
• ソフトウェア開発の歴史を変えた 5 冊の技術書

まとめ

有名 OSS の設計には、技術書と共通の語彙や原則が数多く残っています。Node.js のイベントエミッター、Passport の strategy、コード解析ツールの「臭い」のように、名前ごと辿れるものもあります。一方で、構造が似ているだけの例を本の影響と決めつけると、刊行年と実装年が逆になる取り違えが起きます。本を読んでから OSS のコードを読むと設計の意図が見え、OSS を読んでから本を読むと原則が具体化します。どちらの順序でも、影響を主張する前に作者の言及と時期を確かめる癖をつけると、コードの読み方の精度が上がります。