なぜサードパーティ・ライブラリを避けるべきなのか?
例えば Pythonには標準ライブラリに urllib.request
というモジュールがありますが、高機能なサードパーティ・ライブラリである requests
が普及しています。
しかし、私は先日あるプロジェクトであえてrequests
ではなくurllib.request
を使うことを選びました。友人にそれを話すと少し驚かれましたが、私は以下のような理由から、場合によってはサードパーティ・ライブラリは避けるべきと思っています。
昔話:PythonをBashで書き直した
若い頃あるプログラムを任された私は「RHELなら標準でPythonがインストールされている。このプログラムは RHEL でしか動かさないんだから、Pythonで書いてもいいだろう。PythonはBashより可読性も高いし、クールだ!」と考え、Pythonで書いた結果、先輩にゲンコツ(の絵文字)を食らいました。
というのも、任されたプログラムが、商用パッケージのアップデート用スクリプトだったからです。「RHELでしか動かさない」が、RHEL のバージョンは顧客によりまちまちでした(4.x 〜 5.x)。
Python はバージョンアップの度に文法が追加されるため、複数のバージョンで動くスクリプトを書くのは注意が必要です。さらに、そのスクリプトが将来のバージョン(当時から見ればRHEL 6.x に搭載される Python 2.7)でも動く保証はありません。
一方、Bashは Posix Shellの範囲ならどのRHELでも同じように動作することが期待できます(少なくとも、Pythonより可能性はずっと高い)。
もしアップデートプログラムがコケれば、全国津々浦々にエンジニアが出向いて修復する羽目になるので、可読性が低くても互換性が高いBashで書いたのでした。
サードパーティはコントロールできない
さて、サードパーティ・ライブラリの話です。
サードパーティ・ライブラリはあなたの所有物ではありません。 ゆえに、ライブラリが削除されたり、大きな変更が加わったりすることを止めることはできません。
これが如実に現れたのが、2016年のleft-pad問題でした。
left-pad については、こちらの記事で概要とサードパーティに過度に依存する危うさが述べられています。
NPMとleft-pad : 私たちはプログラミングのやり方を忘れてしまったのか? | POSTD
もちろん、広く使われているライブラリなら、企業が業務の一環で開発していたり、作者が失踪しても fork が作られたりするので、削除されたり致命的な不具合が放置される可能性は低いでしょう。
実際に心配するべきなのは、後方互換性のない変更が加えられることです。 使っていた関数やクラスが廃止されたり、シグネチャーが変わるかもしれません。
そうなったら、あなたは、もはやメンテされていないバージョンを使い続けるか、自分のコードを修正するかの選択に迫られます。
そのサードパーティ、そんなに重要?
さて結局、サードパーティ・ライブラリを使うかどうかは、
- バージョンアップにかかるコスト
- 得られる利便性
この2つを天秤にかけることになります。
書き捨てスクリプトや、頻繁に機能追加するコードなら、バージョンアップのコストはゼロまたは軽微ですから、サードパーティを使っても問題は起きません。 一方、長期間使うが滅多に機能追加はしないコードの場合は、最初に標準ライブラリと多少格闘した方が、後々のコストは安いでしょう。
また、データ分析用のスクリプトを書くとき、pandas
や numpy
といったライブラリは不可欠でしょう(明らかに利便性がコストに勝ります)。一方、同じスクリプトで、処理結果をアップロードするためだけに requests
を導入するというなら、それはちょっと考え直した方がいいかもしれません。