12周年記念パーティ開催！ 2024/5/10(金) 19:00
記事検索
購読 する ログイン

ライブラリ化のススメ 前編 ライブラリ化のメリット

仕事で書いたコードのうち、単体機能をライブラリとして蓄積していくことは、大きなメリットがあります。この記事では、まずライブラリ化のメリットを考えてみます。

カテゴリー
JavaScript >
JavaScriptの設計

発行

著者 高津戸 壮 テクニカルディレクター
ライブラリ化のススメ シリーズの記事一覧

はじめに

筆者、高津戸は、このところ、おおよそ1年〜2年ぐらい、仕事で使うJavaSriptの機能をライブラリにしておくことで、仕事をスムーズに進めることができている気がしています。今回は、ライブラリ化のススメということで、このことについて書きたいと思います。

ライブラリってどういうもの？

普段からWebサイトを作るためにHTMLやJavaScriptを書いている人であれば、jQueryをはじめとした、ライブラリを多く利用しているかと思います。jQueryの場合は、その拡張機能のことをプラグインと呼んでいますね。

今回「ライブラリ」と呼ぶものは、このようなWebサイトで使うJavaScriptのコードを、それなりに汎用化して使えるようにして、まとめたもののことです。早い話、JavaScriptでいえば、ロールオーバーだとか、タブとか、そういった何かしらの機能を実現するためのコードです。

自分で作ったそのようなコードを、ライブラリとしてまとめておくといいよ——というのが、今回の趣旨です。

筆者は、そうやって作ったライブラリを、GitHubにリポジトリを作って置いています。いろいろと仕事をするうちに、かなりの数のライブラリが貯まっていました。

以下が2013年8月時点での、自作ライブラリ一覧です。興味があれば、それぞれ覗いてみてください。私の作っているのは、大体がjQueryプラグインになっています。使い方は「デモ見ろ」としか書いていないものが多いですが……。

ライブラリにすると何が便利か

そんなふうに、自分の書いたコードをライブラリとして整理しておくと、いろいろな点で便利です。どんなことが便利なのか、ひとつずつ見ていきましょう。

あとで使いまわせる

当たり前ですが、一度作った機能を、再び作る手間が省けます。なにかコードを書くときに「あ、これは昔書いたぞ」と、以前自分が書いたコードを探すことはないでしょうか。私はよくあります。しかし、どの時点で書いたのかは、よくわかりません。そんなとき、その機能をライブラリにしておけば、すぐに見つけることができます。場合によっては、そのまま使うこともできるでしょう。

仕事がさっさと終わる

一度作った機能をあとで使えるようにしておけば、当然、仕事がさっさと終わるようになります。その機能は以前作ったわけですから、実質、その機能を作るのに使う時間を、限りなくゼロに近くすることができるからです。いろいろな仕事をやればやるほど、自分のライブラリは溜まっていきます。結果、どんどん仕事にかける時間を短くすることができます。

フィードバックがもらえる

そのように作ったライブラリを、GitHub上に置いておくと、他の人もそのコードを参照できます。ちゃんと他の人が見てもわかるように作っておけば、何かしらのフィードバックがもらえることもあります。GitHubを使ったコーディングについては、以前に外村が記事にしましたので、「ソーシャルコーディングのススメ：GitHubを利用した開発」も参照してみてください。

正直なところ、筆者は、自分でライブラリを作っても、たいして宣伝するつもりがないので、ひたすらGitHub上に置きっぱなしにしているものがほとんどです。しかし、そのようにしていても、たまたまそれを見つけて使ってくれた人が、バグ報告や、機能追加などのメッセージをくれることがあります。

こんなふうに自分の作ったライブラリを公開することで、大げさにいえば、ひとりでは生み出せない価値を創り出すことができるともいえるでしょう。また、ライブラリを公開しておくことは、自分はどのようなことをしているのか、他人に示すのにも有効な方法かと思います。

仕事の一環としてライブラリを作る

まぁ、しかし、前述したようなことは、当たり前といえば当たり前です。おすすめしたいのは、このようなライブラリ化を、業務の一環としてやってしまうということです。

自分の書いたコードをライブラリなどにしていない人は、もしかしたら、ライブラリとしてきっちり整理することは、なにか、その人の趣味であるかのように思っている人がいるかもしれません。筆者は、初めはそのように、趣味的に自分のコードを整理していました。

でも今は、ライブラリ化はプログラムを書く上で必要不可欠なステップであると認識しています。そのライブラリを必ずしも公開する必要はありません。必要なのは、ライブラリとして「分けて考える」ことです。

たとえば、Webアプリを作るとしましょう。そのWebアプリでは、カルーセル、カレンダー、アコーディオン、ダイアログ、タブ、ツールチップ、スライダーを使うと仮定します。これらの機能を、ちゃんと切り分けて考えて設計しないと、すべての機能が複雑に絡まり合うことになってしまいます。結果的に破綻するか、誰も触りたくないコードになってしまいます。

そのような状況を防ぐために、コードは機能ごとにちゃんと分けて設計する必要があるのです。「アコーディオン」であれば、それがひとつで完結するように、「カレンダー」であれば、それがひとつで完結するように、コードを書く必要があります。必要があるといいますか、そのように作った方が便利なのです。

たとえば、カレンダーを表示するコードであれば、うるう年の2月は29日まであるというような、バグになりそうなポイントがあったりします。そのような機能のテストを、ひとつずつちゃんと行っておきたいわけであります。ですがWebアプリ全体で考えると、カレンダーの他にも、ツールチップ、タブ、ダイアログなど、Webアプリを構成するUIがたくさんあります。それぞれについて「この場合はちゃんと動くか？」という機能の確認をいろいろと行う必要があります。これをWebアプリ全体として捉えてしまうと、膨大な数の場合分けで、確認を行わなければならないことになります。

そこで「うるう年の2月は29日まである」というのは、カレンダーの機能についてのテストであり、Webアプリが責任を持つべきものではない——と考えるのです。カレンダーについての機能は、カレンダーのコードで確認できていれば問題ない。Webアプリではそれを使うだけ——と考えます。

そのようにして、Webアプリを構成するひとつのひとつの機能を、ライブラリとして独立した形で作ります。これを繰り返せばWebアプリ自体のコードは、かなりシンプルなものにすることができるでしょう。

逆にいえば、そのくらいキッパリ分けて考えないと、あっという間にコードがぐちゃぐちゃになって、収拾がつかなくなってしまうのです。こういったことを防ぐため、はじめから独立させて作ることができる機能は分けて考えます。そうすれば、後からちゃんとライブラリを整理するまでもなく、ライブラリ化は済みます。仕事をこなせばこなすほど、自分で作ったライブラリを増やしていくことができます。

まとめ

通常考えられるメリットから、さらに一歩突っ込んで、仕事の一環としてライブラリを蓄積していくことのメリットを考えました。

しかし受注案件で書くコードを「どのようにしてライブラリとして独立させるのか？」と疑問に思う人はいるかもしれません。そこで、次回は実際に業務で作った筆者のライブラリを例に、どのようにライブラリ化していけばいいか、解説します。
X GitHub
運営会社