この記事では、「ライブラリ」をうまく使うことの魅力について書いてみました。
フロントエンドでも、バックエンドでも、ライブラリを使って開発するのが主流ですよね。
フロントではnpm, RubyであればGemみたいにそれぞれ対応したライブラリが存在します。
この記事ではライブラリの魅力や、落とし穴について書きいました。
そして、結論は、ライブラリと仲良くなろうです。
たくさんウェブサイトを作るけど、毎回同じようなセットアップをしている。
例えば、よくWordpressサイトを作るのですが、基本cssはbootstrapを使っています。
以前は、カラーリングや色々便利なcssのリストを1つのファイルにまとめて使っていました。
でも、そのリスト自体がどんどん更新されていきますよね。
その度に全てのプロジェクトでcssを更新するのは無駄です。
かといって放置すればどんどん乖離していく。
全てのプロジェクトで共通化したいものを手元で管理していくのには無理があります。
しかし、bootstrapをnpmで管理し始めると自体は急変しました。
記述量は以前の1/100以下になったり、共通部分はライブラリがわでアップデートしてくれる。
こちらはライブラリのバージョンを指定してあげるだけで良い。
管理の手間が一気になくなりました。
まあ、npmでbootstrapをインストールして使うためにnode.jsコンテナを立てたりと一苦労ありますが、そこをクリアしちゃえばとても楽に開発できます。
コードの記述量が圧倒的に減るのは、開発している身としてはこれ以上ないストレス軽減策ですね。
先日、自分が所属するプロジェクトで大変なことが起きました。
そのプロジェクトではフロント側にtypescriptを入れていたのですが、7年前が最終更新のライブラリを使っていました。
さらに、メンテナンスが終了したことを悟ったのか、ライブラリ側のコードをプロジェクト側に取り込んで、継ぎ足し継ぎ足ししながら拡張していたみたいです。
そんなライブラリなのですが、実はメジャーバージョンが2つも出ていた。
つまり、継ぎ足し継ぎ足ししていたファイルはもう使えなくなっちゃってるんですね。
それじゃあ、新しいバージョンの使えばいいじゃん!と思いますが、そうはいきません。
継ぎ足し継ぎ足しされていたコードとライブラリ側のコードがごちゃごちゃに絡み合っているんです。
というわけで、最悪な作業が始まったわけですね。
これがライブラリと付き合っていく中で最大の落とし穴です。
適切に付き合っていかないと、無駄に時間と労力を持っていかれちゃう。
勉強にはなるけど、スピード重視のプロジェクトでは足枷ですね。
ライブラリとうまく付き合うことで、本当にものすごくストレスが改善されます。
コード量は少なく、品質は高く、スピードも出る。
ただ、必要な技術はたくさんあるし、メンテナンスする知識も必要になる。
まあ、チーム開発とか1年以上の開発を考えると、ライブラリと仲良くなれる人とそうでない人で雲泥の差が出るなって思いました。
この記事を書いた人
基本バックエンドなエンジニアですが、デザインとかも好きだったり。 休日はどこかのカフェで何かを勉強してます。 さあ、いろんな話をしましょう! 16パーソナリティは指揮官 (ENTJ-A)です!