0depsムーブメント：ローカル依存関係と不変のコントラクト
ソフトウェア開発者は、しばしば数百もの外部ライブラリをインストールします。現代のフレームワークは、数千もの間接的な依存関係（transitive dependencies）に依存しています。これは、あなたのアプリが、見知らぬ誰かが書いたコードを実行していることを意味します。
このスピードには代償が伴います。ソフトウェア・サプライチェーンのリスクに直面することになるのです。
依存関係が増えるたびに、攻撃対象領域（attack surface）は拡大します。依存関係には以下のようなリスクがあります：
- セキュリティ上の欠陥を混入させる。
- サプライチェーン攻撃の標的になる。
- 作者によって放棄される。
- 公開APIを変更する。
- 後方互換性を損なう。
0depsムーブメントは、この状況を変えようとしています。それは次のような問いを投げかけます。「もし、アプリが自分自身で管理しているコードのみに依存していたらどうなるだろうか？」
0depsモデルでは、必要なすべてのコードをプロジェクトのリポジトリに直接取り込みます。インストール時やビルド時にパッケージをダウンロードすることはありません。リポジトリをクローンした時点で、必要なものはすべてそこに揃っています。
これにより、いくつかのメリットが得られます：
- 再現可能なビルド。
- 外部のパッケージレジストリへの依存がない。
- セキュリティ監査の一元化。
- 高い予測可能性。
- サプライチェーンリスクの低減。
目標は、コードの変化を止めることではありません。アルゴリズムやセキュリティ修正は進化し続ける必要があります。変わらないのは、公開コントラクト（public contract）です。
各ライブラリに対して、安定したインターフェースを設計します。例えば：
authenticate()createSession()verifyPasskey()
これらの関数の背後にある実装は、完全に変わっても構いません。ロジックを書き換えたり、ライブラリを置き換えたりすることも可能です。アプリの他の部分は、その違いに気づくことさえありません。
これにより、アップデート時の最大の悩みが解消されます。通常、バグを修正すると同時にアプリを壊してしまうのではないかと心配になります。しかし0depsなら、公開APIは同一のままです。コードを変更することなく、アプリケーションは動作し続けます。
外部ツールを内部のアダプターの背後に隔離します。もし明日、あるライブラリが使えなくなったとしても、更新が必要なのはアダプターだけです。システムの他の部分は安全なまま保たれます。
0depsはオープンソースを否定するものではありません。オープンソースをより安全に利用したいと考えているのです。動的なインストールを行う代わりに、ライブラリを統合されたコンポーネントとして扱います。監査し、バージョン管理し、カプセル化するのです。
ソフトウェアは何十年も存続します。ライブラリやフレームワークは消え去ります。0depsは、そうしたあらゆる変化の中でも、アプリケーションが稼働し続けることを保証します。
Optional learning community: https://t.me/GyaanSetuAi