モジュール化の簡単な歴史
Josh Emerson
2016年11月21日
0 分で読めます先週、ブライトンで開催されたカンファレンスffconfのスポンサーを務めました。考えさせられる内容から実用的な内容まで、素晴らしい講演が盛りだくさんの一日でした。npmのAshley Williams氏による「モジュール化の簡単な歴史」という講演は、Snykにとって特に関連性が高いと感じたため、その概要をこちらでご紹介します。
この概要に加えて、npm install a-brief-history を実行すればnpmからスライドをダウンロードできます（Ashley氏の講演自体がnpmモジュールになっているのが素敵ですね！）。動画もまもなく公開される予定です（公開され次第、リンクを掲載します）。
なぜモジュール化するのか？
npmは世界最大のモジュールリポジトリです。現在、npmのモジュール数はBower（JS）、nuget（.NET）、Packagist（PHP）、PyPI、Rubygems.orgを合わせた数を上回っています。では、なぜnpmにはこれほど多くのモジュールがあるのでしょうか？
Ashley氏のツイートにはさまざまな反応が寄せられましたが、多くの人がコードをモジュール化する理由として、似たような点を挙げていました。
共通コードを再利用できる
関心事の分離を徹底できる
コードのドキュメント作成やテストが容易になる
なぜモジュール化しないのか？
モジュール化には、複雑さという現実的なコストが伴います。Guy Podjarnyがnpm依存関係の5つの側面で述べているように、実際には想定以上に多くの依存関係に頼っているかもしれません。依存関係ごとに、さまざまな点を確認する必要があります。
やがて、ニーズにおおむね合っていそうなパッケージが見つかります。しかし、本当の課題はここからです。そのライブラリを自分で評価しなければなりません。テストはあるか？ソースコードを理解できるか？積極的にメンテナンスされているか？ドキュメントは簡単に見つかり、参照しやすいか？
Rich Harris – 小さなモジュール、それほど単純ではない
こうした確認事項に加え、セキュリティについても問う必要があります。パッケージのメンテナーは、コードの脆弱性に対処しているか？その依存関係や、さらにその依存関係に既知の脆弱性はないか？
ソフトウェア開発とは変更管理である
モジュール化のメリットとコストを見たうえで、Ashley氏はモジュール化に対する認識と現実の隔たりに焦点を当てています。
ソフトウェア開発と聞くと、問題を解決し、タスクを実行するシステムを作ることを思い浮かべるでしょう。しかし、ソフトウェアは常に進化し、その方向も一定ではないということは、あまり意識されていません。
David Parnasは1972年に「On the Criteria To Be Used in Decomposing Systems into Modules（システムをモジュールに分割する際に用いる基準について）」という本を執筆し、変更管理の観点からモジュール化について考察しています。
[まず]、難しい設計上の決定や、変更される可能性の高い設計上の決定をリストアップする。次に、そうした決定をほかのモジュールから隠すように、それぞれのモジュールを設計する。
この視点からモジュール化を考えると、モジュールの中に複雑さを隠し、システムのほかの部分が実装を気にしなくて済むようにします。
Tefは自身のブログprogramming is terribleで、これを実現する方法を紹介しています。
拡張しやすいコードではなく、削除しやすいコードを書く。再利用可能なソフトウェアを作るのではなく、使い捨てのソフトウェアを作ることを目指すべきです。コードを書くより削除するほうが楽しいことは、言うまでもありません。
まとめ
Ashley氏は、コードのモジュール化は難しいと講演を締めくくります。コードをどのように、いつ分割すべきかを判断するには、理解すべきことがたくさんあるからです。モジュール化の方法やタイミングを決めるうえで大きな課題の一つは、時間という要素が関わることです。ある戦略が自分たちにとって効果的なのか、逆効果なのかを見極められるのは、時間が経ってからです。
