コードを再利用するくらいならOSSにコミットしろ

ムカついたので書く。これは悪口だ。

書き散らかしたコードの再利用なんて時間の無駄#

最近 Twitter にポストしたわたしの経験談だ。

人からJupyter Notebook形式でコード渡された思い出:カギとなる変数X(sklearnのドキュメントに則っていたのだろう、許す)がx1とx2に依存していた(急いでいたのだろう、うん)。x1とx2の定義見に行ったらそれはxに依存していた(ふざけるな)。挙句の果てにxの定義はどのセルにもなかった

— ゆるふわラブストーリー (@515hikaru) 2019年1月26日

こんな経験を複数経た結果、少なくともトライ＆エラーをしているコードを再利用したいなどとは全く思わなくなった。これは人の意識とかいう問題ではない。コードをきれいに書くインセンティブがない以上、そのコードは他者にとって、ひいては未来の自分にとって有益なものにはなりえない。そんなものは資産でもなんでもない、ゴミだ。捨ててしまったほうがいい。

別にゴミを書くなといっているわけではない。むしろ「ゴミをゴミと判断せずに後生大事にとっておく」ことのほうが問題だと思う。生活していてゴミを出すことに怒られはしないが、ゴミを定期的に排除せずそのままにしていると怒られるのだ。

誰かが書いたコードは一切のサポート体制のない品質の低いソフトウェアだ#

わたしは誰かの書いた「コード片」を基本的に一切信用していない。それは自分が書いたものであろうが、世界的なコミッタが書いたものであろうが変わらない。コードを書いたのが人間である限り間違いは存在し得る。だからこそ、OSS であれば信用できない・理解できない挙動が目の前に現れたときはどうしてそのようなことが起きるのかを調査するし、書いた人が身近に存在する場合であれば聞く。お金を払い享受しているサービスやソフトウェアであればサポートに質問をしたりする。最低限、そのような権利を利用者が享受できない場合、わたしはそのソフトウェアやサービスを利用しない。

だから同じ会社・同じ団体に居る人間が書いたコードだからといって無条件に再利用するべきだという神経が全く理解できない。書いている間は同じ組織に居ても書いた人間は退職すれば聞けなくなるし、そもそも仕事で書いたコードのディティールなんてすぐ忘れる。そんな信用できないサポート体制のソフトウェアを誰が使う気になるものか。

再利用する前に “ちゃんと” OSS を使え#

はっきりいって、同じ会社の人間であろうとも所詮は世界的に見ればどこの馬の骨ともわからんただのプログラマだ。当然わたしも。だからそんなわたしたちが書いたコードを再利用するよりも scikit-learn を利用したほうがよっぽどいい。scikit-learn に train_test_split という API がある けど、わたしは自分でもこれに類する実装をしたことあるし¹、ほかの人の実装を読んだこともある。でも scikit-learn の API が一番使いやすく万能で正確だと思う。これの別実装が本当に「あなたは」必要か?

もしもコードレベルで再利用したいなら独自実装を極力減らせ、オーバーエンジニアリングをやめろ、 OSS をちゃんと使いこなせ。

本当に「再利用」できるもの#

コードは再利用できないと考えたほうがいい。できる部分はすでに OSS 化されていると考えて差し支えない。結局再利用できる/できないはデータ構造にかかわるので、保存されているデータ形式が異なればコードは異なる。だからデータ構造が異なれば著名 OSS よりも踏み入れたコードの再利用は不可能だ。

本当に必要なのは再実行できるコードではなく、全員がいつでも簡易的な再実装をできるようにすることだ。解きたい問題、解決したい課題がある。毎日小さな課題を解き続けるのが試行錯誤とかトライ＆エラーとかいうものの作業内容だ。しかし人によって微妙に状況は異なるし、同じコードは使えない。だからこそ、我々は誰でも「自分の状況にあったコード」を書けるようになるべきなのだ。わたしがやっても、あなたがやっても、コードは違うけどかかる時間は同じ。そんな状態が理想だ。

Amazon.co.jp： シェルプログラミング実用テクニック eBook: 上田隆一, USP研究所: Kindleストア

微妙に異なるものをたくさん作るのは一見非効率だが、すべての「微妙に異なる」パターンを全て吸収することは非常に難しい。それをやっている時間があるなら最初から OSS の API を叩いたほうが早いし、そうあるべきだ。

OSS を利用するコードをゼロからかける力もないのにプログラマ名乗っている人なんてさすがにいないだろう。