“変更は唯一の定数です…”–Heraclitus(Philosopher)
今日のwebアプリケーションを構築するために使用するツール、ライブラリ、フレームワークは、ほんの数年前に使用したものとは大幅に異
今から数年後には、これらの技術のほとんどが再び劇的に変化しているでしょう。 しかし、私たちの多くは、これらの我々のアプリの中心的な、不可解な部分を作ります。
私たちは、月の風味のフレームワークをインポートし、使用し、継承します。 まあ…彼らはそうではありません。 そして、それは問題です。
webアプリケーションの開発、設計、および設計の20年以上の後、私は二つの重要な真実を理解するようになりました:
- 外部の依存関係は、アプリケーションの長期的な安定性と実行可能性に大きな脅威をもたらします。
- 外部の依存関係を活用せずに、あらゆる種類の非自明なアプリを構築することは、不可能ではないにしても、ますます困難になっています。
この記事は、我々のアプリが長期的な生存の最大のチャンスを持っているように、これら二つの真実を調整することについてです。
確かにウサギの穴は非常に深いです。
私たちのwebアプリが依存しているすべてのことを考え始めると、コードに到達する前に十数以上を考えるのは簡単です:
- 電源
- 接続
- ファイアウォール
- DNS
- サーバーハードウェア（CPU、ディスク、Ram、…）
- 冷却
- 仮想化プラットフォーム
- コンテナプラットフォーム
- コンテナプラットフォーム
- コンテナプラットフォーム
- コンテナプラットフォーム
- コンテナプラットフォーム
- コンテナプラットフォーム
- コンテナプラットフォーム
- コンテナプラットフォーム
- コンテナプラットフォーム
- コンテナプラットフォーム
- オペレーティングシステム
- Webサーバープラットフォーム
- App Serverプラットフォーム
- webブラウザ
開発者として、これらのことを認識するのは良いことですが、 だから、今のところそれらを無視して、コードについてのみ話しましょう。
コードには、3種類の依存関係があります。
1。 私たちがコントロールする依存関係
これは私たちまたは私たちの組織によって書かれ、所有されているコードです。
2. 依存関係私たちは制御しません
これはサードパーティのベンダーやオープンソースソフトウェアコミュニティによって書かれたコードです。
3. 一度削除された依存関係
これらは、サードパーティのコードの依存関係が依存するコードの依存関係です。 （三倍速いと言う！)
私たちは主に私たちが制御しない依存関係について話します。
私たちが制御する依存関係と、一度削除された依存関係は依然として頭痛を引き起こす可能性がありますが、私たちが制御する依存関係の場合、
いったん削除された依存関係の場合、通常はサードパーティに依存して処理することができます。
サードパーティのコードの依存関係が良い理由
webアプリケーションの大部分は、一般的な問題を解決するために存在します: 認証、承認、データアクセス、エラー処理、ナビゲーション、ロギング、暗号化、項目のリストの表示、フォーム入力の検証など。..
どの技術スタックを使用しているかにかかわらず、これらの問題に対する一般的な解決策が存在し、コードベースに簡単に取得してプラグインできるラ 完全にゼロからこのようなもののいずれかを書くことは、一般的に時間の無駄です。
一般的でない問題を解決するか、一般的な問題を一般的な方法で解決するコードに集中したいとします。 アプリだけに固有のビジネスルールを実装するコード、つまり”秘密のソース”です。”
Googleの検索とページランキングアルゴリズム、Facebookのタイムラインフィルタリング、Netflixの”recommended for you”セクションとデータ圧縮アルゴリズム—これらすべての機能の背後にあるコードは”secret sauce”である。”
サードパーティのコード-ライブラリの形で—あなたはすぐにあなたのアプリのそれらのコモディティ化された機能を実装することができますので、あな”
なぜサードパーティのコードの依存関係が悪いのか
ここ数年で構築された自明でないwebアプリを見てみると、実際にサードパーティのライブラリから来たコードの量には絶対に驚かされるでしょう。 これらのサードパーティ製ライブラリの1つ以上が大幅に変更されたり、消えたり、壊れたりした場合はどうなりますか？
それがオープンソースなら、おそらくあなたはそれを自分で修正することができます。 しかし、あなたが所有していないライブラリ内のすべてのコードをどれだけ理解していますか？ 最初にライブラリを使用する大きな理由は、すべての詳細を心配することなくコードの利点を得ることです。 しかし、今、あなたは立ち往生しています。 あなたは完全にあなたが所有していないと制御しないこれらの依存関係にあなたの幸運を結んできました。
おそらく、あなたは私が誇張していると思うか、純粋に学術的な観点から話していると思います。 私はあなたを保証してみましょう—私は完全に自分のアプリにあまりにも緊密にサードパーティのコードを埋め込むことによって自分自身をsnookeredクライ 最近の例を1つだけ示します…
私の元クライアントは、Facebookが所有するParseと呼ばれるBackend-as-a-Serviceプロバイダを使用してアプリを構築しました。 Parseが提供するJavaScriptクライアントライブラリを使用してParseサービスを使用しました。 その過程で、彼らは「秘密のソース」コードを含むすべてのコードをこのライブラリに緊密に結合しました。
私のクライアントの最初の製品発売から三ヶ月後—彼らが本物の、有料の顧客といくつかの良い牽引力を得始めたのと同じように—Parseは、それがシャッ
今、彼らの製品を反復し、顧客基盤を成長させることに焦点を当てるのではなく、私のクライアントは、自己ホスト型のオープンソース版のParseに移行するか、Parseを完全に置き換える方法を理解しなければなりませんでした。
これは若い、駆け出しのアプリケーションのために引き起こした混乱は、私のクライアントは、最終的に完全にアプリを廃棄するように巨大でした。
善と悪のバランスをとる
数年前、サードパーティのライブラリの利点を維持しながらリスクを克服するための私の解決策は、アダプタパターンを使用してそれらをラップするこ
基本的には、サードパーティのコードを記述したアダプタクラスまたはモジュールにラップします。 これは、あなたが制御する方法でサードパーティのライブラリの機能を公開するために動作します。
このパターンを使用すると、サードパーティのライブラリやフレームワークが変更されたり消えたりする場合は、アダプターコードを少し修正するだけです。 アプリの残りの部分はそのまま残ります。
これは紙の上で良い音。 いくつかの機能しか提供しない自己完結型の依存関係がある場合、これはそのトリックを行います。 しかし、物事は速く醜い得ることができます。Reactライブラリ（JSXを含む）全体を使用する前にラップする必要があると想像できますか？ JQuery、Angular、またはSpring frameworkをjavaでラップするのはどうですか？ これはすぐに悪夢になります。
最近は、より微妙なアプローチをお勧めします…
コードベースに追加する依存関係ごとに、二つの要因を掛けて導入するリスクのレベルを評価します:
- 依存関係が重要な方法で変化する可能性。
- 依存関係への重大な変更がアプリケーションに与えるダメージの量。
サードパーティのライブラリやフレームワークは、次のことの一部またはすべてが真実である場合に変更される可能性が低くなります:
- それは数年前から出回っており、いくつかの主要なリリースを持っていました。
- 多くの商用アプリケーションで広く使用されています。
- それは大規模な組織、好ましくは家庭の名前の会社や機関の積極的なサポートを持っています。
サードパーティのライブラリやフレームワークは、次のことの一部またはすべてが真実である場合、アプリケーションへのダメージが少なくなります:
- これは、アプリケーション全体で使用されるのではなく、アプリケーションのごく一部でのみ使用されます。
- それに依存するコードは、私が以前話した”秘密のソース”の一部ではありません。
- 削除するには、コードベースの変更を最小限に抑える必要があります。
- あなたのアプリケーション全体は非常に小さく、すぐに書き換えることができます。 （これには注意してください—それは非常に長い間真実ではありません。)
危険なものは、あなたがそれを包むか、またはそれを完全に避けるべきである可能性が高くなります。
アプリケーションの価値提案の中心となるコード—あなたの”秘密のソース”—に関しては、それを非常に保護する必要があります。 そのコードを可能な限り独立したものにします。 依存関係を絶対に使用する必要がある場合は、直接参照するのではなく、それを注入することを検討してください。 それでも、注意してください。
これは、あなたが本当にクールだと思うサードパーティのライブラリに”いいえ”と言ったり、何らかの理由で本当に使いたいと思うことを意味します。 強くなれ。 私を信じて、それは報われる。 Angularの最初のリリースに多額の投資をしたすべての人、またはParseをどこでも使用した私の元クライアントに尋ねてください。 それは楽しいことではありません。 信じて
楽しいといえば、これを見てみてください…
上の画像は、TinyTag Explorerというアプリケーションの依存関係グラフです。
既存のアプリの依存関係グラフを生成することは、依存関係によって導入されるリスクのレベルを理解するのに最適な方法です。 JavaScript、C＃、Java、PHP、Pythonなど、さまざまな言語で上記と同様のグラフを生成するための無料のツールのリストをまとめました。 あなたはここでそれを得ることができます。
ヘルプ私は他の人を助ける
私は彼らと私の知識と経験を共有することによって、私はできるだけ多くの開発者を助けたいです。 下の▼おすすめボタン（緑のハート）をクリックして私を助けてください。
最後に、ここで無料の依存関係グラフ生成器のリストを取得することを忘れないでください。