僕がプログラマーになった20代前半の時期は、ちょうどRubyやPythonが日本でもキャズムの峠を越え始めたあたりだったようにおもう。
なので最初の数年間は、当初の所属組織がSIerやハードウェア寄りのお堅い環境だったのもあって
「OSSはとにかく最高でバンバン使え」
「（他人が作った）小さいパーツをとにかく組み合わせろ」
「自分で書いたコードは少ないほど良い」
という当初の風潮を無邪気に信用していたようにおもう。
（とはいえ僕がプログラミングを覚えた言語であるPythonは他と比べると比較的堅実で、標準でできることをちょっと楽に書けるだけのライブラリは入れるんじゃねえ！というような文化はあった）
現代でもそうなのかは知らないが、当時のSIerはほんの少しの不確実性が混じるくらいなら確実で再現性のある失敗を選ぶといった感じで、とにかく技術的にまともなライブラリ選定というものは存在しなかったので論外だが、ハードウェア寄りの堅い仕事をする場合にライブラリの選定はかなり保守的になる。
当時はそういうのに結構反発したようにおもう。まあ、未熟だったのだ。
翻っていまはどうか？
僕がフロントエンドのライブラリを導入する際に考えることはこれだ：
- これは定番と言えるくらい有名か？
- 自分で簡単に作れないか？
- コードの品質は高いか？（メンテナが飽きたらフォークして引き継ぐ自信はある？）
- やりたいことに対して無駄に多機能すぎないか？
- 機能限定版なら半日くらいで自作できるんじゃないか？
- 同じことが標準（や準標準）ライブラリで書けるのでは？
- ドキュメントはしっかりしているか？
- ドキュメントが貧弱な場合、コードを読んで機能を逆引きすることになる。じゃあ自作した方が早くないか？
- 次々と無意味なAPI変更をいれるようなことはないか？
どんだけこいつ自作したいんだよ。
つまり僕は
- 自作するとけっこう面倒くさい（もしくは僕には作れない）
- コードの品質が高い
- ドキュメントが整備されている
- 安定した有名なライブラリ
という条件が満たされた場合にだけインストールを許可しているようだ。
一体どういうことだろう？
gemをたくさん引っ張ってくるのがクールなやり方だったんじゃないのかよ。自分で書いたコードが少ないほどメンテが楽でクオリティも高いんだろ？
自作よりも、どっかのハッカーが書いてくれたライブラリのほうが品質が高いし、世間で広く知られているんだから学習コストも低いだろ！
つまり、そういったインチキにうんざりしたからなんだな。
もちろん、世の中には優れたライブラリがたくさん存在する。
僕もそういったプロダクトにはおおいにお世話になっている。Reactとか。Reactはこんだけ世界中でインストールされているのに本当に破壊的変更や機能追加が少なくてマジでえらい。アクティブな定期更新の10000万倍難しいことをしているし、開発元であるFacebookのWebフロントエンドの挙動が本当にクソなのは流石にもうちょっと真面目にやれよとおもう。
しかし世の中には結構ヤバイ品質のコードがゴロゴロしている。
結構な数の利用者がいるReactプラグイン、みたいなやつも平気でrender内で副作用を書いていてちょっとしたことで無限ループに入ったりする。
そういうのにはひとつひとつPRを送っていったりするのが人としては正しい姿なのかもしれないが、こういうレベルのルールを破っているとなるとかなり厳しいのでめんどくさくなり、ちゃちゃっと自分で書くか……となってしまう。
ライブラリの自作、というと身構える人も多いとおもう。
実際、どんなに小規模であっても「OSS化できるような、独立した汎用的なモジュールを書く」というのはちょっとした特殊技能のようであまりできる人を見かけない。
が、純粋な技術的にはそんなに難しいことはないのがほとんどだ。
例えばいまはもう消滅してしまったっぽい？（ガチで興味がなくて追いかけてないから知らん） react-router を例にとろう。
僕はver3だかを試しに使っていたような覚えがある。使い始めてver4かな？が出現してきて、それが全く本質的なアップグレードが存在しないのにAPIが変わりまくるという最悪なものだった。
どんなroutingライブラリも、究極的にはブラウザのhistory apiを操作しているだけだ。
もうちょっというと、history apiは実際ちょっとだるいし、mockしたりするのが大変なのでhistoryというパッケージを使っていることがおおい。
御多分に洩れず、react-routerの本質的な中身はhistoryパッケージが8割といったところで、あとは余計な贅肉だった（少なくとも当時の僕のプロジェクトでは）。
呆れた僕はマネージャーに掛け合って工数をもらい、自作したやつで様子見をさせてもらうことにした。
確か3時間もかからずに完成した覚えがある。
なぜそんなに早くできたのかというと、僕が作ったrouterは数割程度の機能しか持たなかったからだ。もっというと、その程度のことしかしないのにreact-routerみたいな巨大パッケージをインストールしていたからだ。
だから自分のところで使う機能にのみ集中すれば、ver3から4への乗り換えよりも短い時間で自作できた。しかもpackage.jsonに発生する依存は history のみだ。
Go言語の風習は好きでないものが多い（とはいえ登場から10年も経って当初苦手だった部分もだいぶ軟化しているようだ）が、なんでもかんでも外部パッケージを入れるなよ！標準でやれるならそれでやれという習慣は本当に素晴らしいとおもう。
JavaScriptがモダン化するにあたって、参考にすべきはGoの文化だったのだが、さまざまな文化的背景ーーjQueryバンザイーーや人の流れなんかもあり実際にはRuby的なgemいれまくりモテまくりが主流になっているのはちょっと悲しい。
とはいえこれに関してはブラウザという環境ゆえの事情なんかもあり、不可避だったかなとはおもう。
しかしフルスタックっぽいフレームワークを避けて、なるべく個別のライブラリを組み合わせて最強のデッキを作る……という良い流れになっていたのに最近は猫も杓子もフルスタックへと回帰する雰囲気になっているのは非常に気になる。
長くなりそうなので一旦まとめるが、色んな組織がもっとライブラリを自作してもいいんじゃねえかなと僕はおもっている。RoRやNextみたいな規模のライブラリでですらレールに乗らないボイラープレートは出てくるわけだし。
汎用性のあるコードを書くことに対するビビり？みたいなものがあるのかなと愚行しているが、実際のところはわからない。
自分の書いた汎用モジュールを他メンバーに使わせる、という形になるわけでそれは確かに何らかの後ろめたさみたいな感情はでてくるかもしれない。
しかしまあOSSへのコントリビュートは市民の義務だし、社内ライブラリへの貢献は社員の義務なのだ。
＊ ＊ ＊
文字媒体の制限もあり色々と端折ったが、とにかく依存ライブラリは少なければ少ないほどよい。
なんてことを昔の自分が聞いたらワーワー言ったのかもしれないなと懐かしく思いました。
つづく（？）
