なぜサードパーティ・ライブラリを避けるべきなのか?

例えば Pythonには標準ライブラリに urllib.requestというモジュールがありますが、高機能なサードパーティ・ライブラリである requests が普及しています。

しかし、私は先日あるプロジェクトであえてrequestsではなくurllib.requestを使うことを選びました。友人にそれを話すと少し驚かれましたが、私は以下のような理由から、場合によってはサードパーティ・ライブラリは避けるべきと思っています。

昔話:PythonBashで書き直した

BashPythonで」ではありません。

若い頃あるプログラムを任された私は「RHELなら標準でPythonがインストールされている。このプログラムは RHEL でしか動かさないんだから、Pythonで書いてもいいだろう。PythonBashより可読性も高いし、クールだ!」と考え、Pythonで書いた結果、先輩にゲンコツ(の絵文字)を食らいました。

というのも、任されたプログラムが、商用パッケージのアップデート用スクリプトだったからです。「RHELでしか動かさない」が、RHEL のバージョンは顧客によりまちまちでした(4.x 〜 5.x)。

Python はバージョンアップの度に文法が追加されるため、複数のバージョンで動くスクリプトを書くのは注意が必要です。さらに、そのスクリプトが将来のバージョン(当時から見ればRHEL 6.x に搭載される Python 2.7)でも動く保証はありません。

一方、BashPosix Shellの範囲ならどのRHELでも同じように動作することが期待できます(少なくとも、Pythonより可能性はずっと高い)。

もしアップデートプログラムがコケれば、全国津々浦々にエンジニアが出向いて修復する羽目になるので、可読性が低くても互換性が高いBashで書いたのでした。

サードパーティはコントロールできない

さて、サードパーティ・ライブラリの話です。

サードパーティ・ライブラリはあなたの所有物ではありません。 ゆえに、ライブラリが削除されたり、大きな変更が加わったりすることを止めることはできません。

これが如実に現れたのが、2016年のleft-pad問題でした。

left-pad については、こちらの記事で概要とサードパーティに過度に依存する危うさが述べられています。

NPMとleft-pad : 私たちはプログラミングのやり方を忘れてしまったのか? | POSTD

もちろん、広く使われているライブラリなら、企業が業務の一環で開発していたり、作者が失踪しても fork が作られたりするので、削除されたり致命的な不具合が放置される可能性は低いでしょう。

実際に心配するべきなのは、後方互換性のない変更が加えられることです。 使っていた関数やクラスが廃止されたり、シグネチャーが変わるかもしれません。

そうなったら、あなたは、もはやメンテされていないバージョンを使い続けるか、自分のコードを修正するかの選択に迫られます。

そのサードパーティ、そんなに重要?

さて結局、サードパーティ・ライブラリを使うかどうかは、

  • バージョンアップにかかるコスト
  • 得られる利便性

この2つを天秤にかけることになります。

書き捨てスクリプトや、頻繁に機能追加するコードなら、バージョンアップのコストはゼロまたは軽微ですから、サードパーティを使っても問題は起きません。 一方、長期間使うが滅多に機能追加はしないコードの場合は、最初に標準ライブラリと多少格闘した方が、後々のコストは安いでしょう。

また、データ分析用のスクリプトを書くとき、pandasnumpy といったライブラリは不可欠でしょう(明らかに利便性がコストに勝ります)。一方、同じスクリプトで、処理結果をアップロードするためだけに requests を導入するというなら、それはちょっと考え直した方がいいかもしれません。