Mistake #89 : Framework Cult

崩れゆく
依存の塔

「とりあえずReactで」。
3ページの紹介サイトを作るのに、数百のnpmパッケージをインストールしました。
半年後、依存関係のバージョン競合が発生し、ビルドさえ通らなくなる未来が見えます。

🧱 ジェンガ体質診断
  • `npm install` が終わるまで5分以上かかる
  • `package.json` の依存ライブラリの数が50を超えている
  • ライブラリのアップデートを試みると、必ず何か壊れるので放置している
  • jQueryで十分な機能なのに、あえてSPAフレームワークを使っている
⚠️ 警告:あなたのアプリケーションは、他人のコードの重みで圧死寸前です。
依存が増えれば増えるほど、あなたがコントロールできる部分は減っていきます。

01. 依存のコスト

🃏⛺️
npm audit: 99 vulnerabilities found

「車輪の再発明をするな」は真実ですが、だからといって「タイヤ交換のために車ごと買い替える」のは馬鹿げています。
1つの小さな機能(例えば日付フォーマット)のために、巨大なライブラリを丸ごと導入する。
これを繰り返すと、アプリのサイズは肥大化し、読み込み速度は低下し、セキュリティリスクは増大します。

コードを書かないことが
最も早い実装ではない。
依存を減らすことだ。

02. プレーンな実装を見直す

現代のブラウザ(Vanilla JS/CSS)は非常に強力です。
昔はjQueryが必要だった処理も、今は標準APIで1行で書けます。
フレームワークを剥がしても動く「コア」を大切にしてください。
流行り廃りの激しいフロントエンド界隈で生き残る唯一の方法は、基礎技術への回帰です。

03. マイクロライブラリの活用

どうしてもライブラリが必要な場合は、単機能で依存の少ない「マイクロライブラリ」を選びましょう。
そして、導入する前に「ソースコードを読んで理解できるか」を確認してください。
理解できないブラックボックスを、あなたの製品の核にしてはいけません。

執筆:ソフトウェアアーキテクト

構造の守護神。
「依存」を「負債」と定義し、可能な限り依存を排除した、長寿命なアーキテクチャを設計する。