車輪の再発明は避ける - 技術をかじる猫

プログラマなら何度も聞いた筈。
でも、実際に車輪の再発明って結構やってるのでは？

車輪の再発明とは？

何のことはない、同じようなものを何回も書く事をいう。

例えば、AJAX API を作るという場合なら、XML/JSON でシリアライズ/デシリアライズの環境を整えて、レスポンスヘッダを弄って、オブジェクトのシリアライズ結果をレスポンスのストリームに書き込む…

何言ってんだレベルだよね。

例えば Spring なら、コントローラに「RestController」をアノテートして、オブジェクトをそのまま返せば済む話だったりする。
Play なら、Json オブジェクトにクラスを食わせて結果を返すだね。

CSRF 対策だって、自前でセキュアなワンタイムトークンを作るとか阿呆な所業だ。

こういう技術の実現をより低レベルから構築することが車輪の再発明という。

何故避ける？

大体の事ははてなキーワードに書いてある。

標準で提供されているものは注意深く検討した上で作成されており、バグは少なく、処理も速いため、余程のことがない限り作成のために使った時間と金をロスするだけである。
商用システム上で車輪の再発明を行ってしまった場合は作成した後も、試験・運用などの開発フェーズでも面倒を見る局面がありコストは更に嵩む。
また担当SEやプログラマが入れ変わった場合に、再発明された機能のコードまで含めて勉強させなければならないため、無駄になるコストは意外とバカにならない。
ただ、あえて再発明をする必要がある時もある。例えば現状のプログラムがなんとか動いているのだがコードがスパゲッティになってしまい、それ以上の拡張性を期待できなくなった時などである。
しかし、多くの場合は設計がまずいことが多いため、リファクタリングを行ったほうが適切である。

誰が好き好んでスパゲティコードなんて弄るか！
ライブラリを使えば、増量ソースが少なくて済む。

たまに「その学習コストが…」なんていう阿呆が居るが、何も極めろなんて言ってないし、求められる事も普通ない。
「お前の学習コストは、JSON 一つ覚えるのに月単位もかかるのか？」と問いたい（むしろかかるならその学習能力のなさを驚きたい）。

後、ライブラリを使うことには意味がある。
「Excelで帳票出して」と言われて、Excel のバイナリファイルの仕様を１から勉強して自力で実装するのと、 Apache POI 覚えるのどっちがいい？

つまりそういう事だ。

車輪の再発明ってどうやって避けるのか？

これには、まず自分がやろうとしている事が、本当に自分でやるべき事なのかを考えることから始まる。
だが、ここが一番の問題なんだ。

「CSVパースだって機能を実現するためのやるべきことだ」なんて思ってると、車輪の再発明はなくならない。

まずこれの切り分けが無いと、何度でも車輪の再発明を繰り返してしまう。
この認識だと、「沢山のライブラリを知ってれば、簡単に解決できるものを選べるよね？」という解決法になってしまう
これでは 「ライブラリや OSS を探そう」という発想が生まれない

そのヒントは実は昔の論文にある。
以下はその抜粋だ

魔法のように、すぐに役に立ちプログラマの生産性を倍増させるような技術や実践 (特効薬) は、今後10年間（論文が著された1986年の時点から10年の間）は現れないだろう、と主張した。
ログラマの生産性の限界は「本質的な複雑性」（essential complexity）についてのみ当てはまると述べているのであり、「偶有的な複雑性」（accidental complexity）に対する挑戦については支持している。
* 偶有的な複雑性は、ソフトウェア開発者自身が発生させている解決可能な問題に関連する。例えば、アセンブリ言語のプログラムコードの記述、最適化、バッチ処理などによってもたらされる遅延は、偶有的な複雑性に由来する。
* 本質的な複雑性は、解決すべき問題によってもたらされるものであり、これを取り除くことはできない。もし利用者が30の異なることを行う1つのプログラムを望む場合、この30のことは本質的であり、開発するべきプログラムはこの30の異なることを実行しなければならない。

銀の弾丸などない –Frederick Phillips Brooks, Jr. 氏の論文

超平たく言うと、「本質的な複雑性（≒要件）は時代とビジネスで変わるんだから、特効薬なんてあるわけないよ。でも偶有的な複雑性（≒要件を実現するための手段）はどんどんやれ」って事だ。

つまり、作る前に考えればいい。

「これから書こうとしているコードは要件そのものなのか？それとも、要件実現のための技術の一つなのか？」 そこが切り分けられれば、ライブラリを探すことができる。

この切り分けがしにくいなら、そもそもメソッド化やクラス化の単位が分かってないか、何が一般的技術（XML,JSON,Ajax等）なのかを知らない。
そういう人はまだ設計を行うべきではない。

大丈夫だ、技術なんてものは、ライブラリなんてものは使う為に作られてる。
つまり勉強することはできるんだ。