博士

ロボ子、今日のITニュースは「依存関係は無料じゃない」という話じゃ。

ロボ子

依存関係って、ライブラリとかフレームワークのことですか？

博士

そうじゃ、それを使うことで、自分でコードを書かなくて済む便利なものじゃな。でも、ただではないんじゃ。

ロボ子

コストがかかる、と。

博士

そう。「学習コスト」「変更コスト」「配布コスト」の３つがあるんじゃ。

ロボ子

学習コストは、新しいライブラリの使い方を覚える時間ですね。

博士

その通り！そして「破壊的な変更により、コードの書き換えが必要になる場合がある」んじゃ。

ロボ子

APIが変わって、古いコードが動かなくなる、みたいな。

博士

そうそう。さらに「クライアントの環境に確実に存在するようにする必要がある」んじゃ。配布コストじゃな。

ロボ子

依存ライブラリを一緒に配布したり、インストール手順を説明したりする必要があるんですね。

博士

そういうことじゃ。Tigerbeetleというプロジェクトは、Zigツールチェーン以外は依存関係をゼロにするポリシーらしいぞ。

ロボ子

徹底してますね。

博士

依存関係を評価するためのフレームワークもあるんじゃ。「Ubiquity（普及度）」「Stability（安定性）」「Depth（深さ）」「Ergonomics（人間工学）」「Watertightness（水密性）」の5つじゃ。

ロボ子

それぞれ詳しく教えてください。

博士

「Ubiquity」は、どれだけ広く使われているか。ターゲット環境に最初から入っているか。「Stability」は、変更の頻度。「Depth」は、APIの下にある機能の量じゃ。

ロボ子

なるほど。

博士

「Ergonomics」は、APIが使いやすいか。「Watertightness」は、抽象化が漏れないか、じゃ。

ロボ子

抽象化が漏れる、というのは？

博士

例えば、データベースの抽象化を使っていても、SQLの知識が必要になる場合じゃ。抽象化が不完全だと、下の層の知識が必要になるんじゃな。

ロボ子

理解しました。

博士

良い依存関係の例は、「POSIXシステムコール」「ECMA-48ターミナル制御コード」「Webプラットフォーム」じゃ。

ロボ子

POSIXシステムコールは、LinuxとかmacOSで使える標準的なAPIですね。Webプラットフォームは、ブラウザで動くJavaScriptとかHTMLとか。

博士

そうじゃ。これらは「広く普及しており、下位互換性への取り組みも大きい」んじゃ。

ロボ子

悪い依存関係の例は、この記事では読者への課題として残されているんですね。

博士

ロボ子は何だと思う？

ロボ子

うーん、頻繁にAPIが変わるライブラリとか、ドキュメントが少ないフレームワークとかでしょうか。

博士

正解！ 依存関係は便利だけど、ちゃんと選ばないと痛い目を見るぞ！…って、まるで恋愛みたいじゃな！