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

最近のプログラミング言語¹は標準ライブラリが充実していますが、標準ライブラリが使いにくいために、別のサードパーティが普及している事も多いです。

例えばRubyでは、標準ライブラリのnet/http に対し、faraday がよく使われます。

しかし、私は先日あるプロジェクトであえてfaradayを避けnet/httpを使うことを選びました。私は以下のような理由から、サードパーティ・ライブラリは避けるべき(時もある)と思っています。

昔話：Pythonをシェルスクリプトで書き直した

「シェルスクリプトをPythonで」ではありません。

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

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

Python では複数のバージョンで動くスクリプトを書くのは注意が必要です（2.4にはwith文が無い！）。気を付けて書いたとしても、そのスクリプトが将来のバージョンでも動く保証はありません（2.5ではwithという変数名は使えない！）。

一方、シェルスクリプトはどのRHELでも同じように動作することが期待できます（少なくともPythonよりは確実性が高い）。

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

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

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

これが如実に現れたのが、2016年のleft-pad問題でした²。left-padというライブラリが公開停止されたことで、それを（間接的に）利用するReactやBabelなどの有名ライブラリも動作しなくなったのです。

「left-padは極端な例だろう」「有名ライブラリが公開停止されることはない」と思われるでしょう。

でも、有名ライブラリもメジャーバージョンアップで後方互換性が無くなることは珍しくはありません。旧バージョンの利用者から見ると、実質的には開発終了と同じです。

もし、旧バージョンに深刻な不具合・脆弱性が見つかった場合、利用者であるあなたは、

1. 自分のコードを新バージョン向けに修正する（もちろん、テスト等の工数もかかる）
2. もはやメンテされない旧バージョンを使い続ける（場合によってはフォーク版を作る）

という選択に迫られます。

こんなリスクを追うぐらいなら、多少不便でも標準ライブラリで書いた方が良いのではないですか？

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

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

• バージョンアップ時の書き換えにかかるコスト
• 得られる利便性

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

あなたが書いているのが「長期間使うが滅多に変更はしないコード」の場合は、「最後に触ったのが3年前だから勘所が思い出せない」「開発環境構築から始めないといけない」「保守フェーズなので工数が取れない」といったことが起きがちなので、最初に標準ライブラリと多少格闘した方が、後々のコストは安いでしょう。一方、書き捨てスクリプトや、頻繁に手を加えるコードなら、書き換えのコストはゼロあるいは低くなります。

また、例えばPythonでデータ分析処理を書くとき pandas や numpy といったライブラリは不可欠でしょう（明らかに利便性がコストに勝ります）。一方、付加的な処理（分析結果の保存とか）で楽をするためにrequests を導入するというなら、それはちょっと考え直した方がいいかもしれません。

1. "Batteries included" が売りのPythonは1991年登場なので「最近」という表現はちょっと変ですが。 ↩

2. left-pad については、こちらの記事で解説されています: NPMとleft-pad : 私たちはプログラミングのやり方を忘れてしまったのか？ | POSTD ↩