車輪の「再発明」と「再実装」を分けて考える
ソフトウェア開発で既存ライブラリや先行事例があるにもかかわらず、様々な理由でそれを利用せず、コードやプログラミング技法を再び一から作ってしまうことを「車輪の再発明」と呼び、無駄なコストとして非難される場面が多い。
オブジェクト指向プログラミングのメリットを宣伝する時にも、OOPの機能を活用した再利用可能なライブラリによるプログラミングの省力化という観点から「車輪の再発明をする必要はない」という風に持ち出される事が多い。
自分は「車輪という"アーキテクチャ"の再発明はする必要が無いが、車輪という"物体それ自体"は自分で創る必要がある場合も多い」という意見で、gihyo.jpの記事に絡めたエントリを書いたことがある。：[雑記]いい加減「車輪の再発明」の暗喩を使うのはどうかと思うが。 - ぐらめぬ・ぜぷつぇんのはてダ
今回、さらにすっきりと綺麗にまとめられたエントリを発見したのでこちらでも取り上げておきたい。
自分は「車輪の再発明」と「車輪の再実装」は完全に異なると考えていて、
http://d.hatena.ne.jp/Isoparametric/20091230/1262134418
「車輪の再発明」で無駄に頭を悩ませる必要はないですが、
寧ろ「車輪の再実装」は非常に重要だと考えています。
ただ、「車輪の再実装」は習作でしかないことも多く、
習作は習作だということです。
このエントリはソフトウェア技術の学習やソースコードリーディングという観点から、車輪の再発明を「再発明」と「再実装」に切り分けた上で、「自分なりに再実装することで、既存のライブラリの機能やソースコードをより詳しく理解する助けやきっかけになる」と述べている。
これには全く同意見で、自分の場合はPHPのWebアプリのフレームワークでまさに同じ事を感じた。一旦完成系、つまりstableリリースに到達したWebアプリケーションのフレームワークのソースコードは、PHPとWebアプリをちょこっと囓った程度の人間には理解出来ないほどの技巧が詰め込まれている。それを理解する為の手法の一つとして、自分は「オレオレフレームワーク」、つまり自作のフレームワークを作ることで、MVCやDB周りの処理の共通化・自動化などを「再実装」した。その経験があったからこそ、symfonyやcakephpのフレームワークを使うことになっても特に躓くことなく、フレームワークのソースコードを読みこなすことが出来た。
とはいえ、MVCやDBのテーブルの自動マッピングなどの概念を「再発明」したか？と言われればNOだった。特にイベント駆動のフレームワークであるXhwlayの時などは、アイデア自体はPieceProjectが既に実装していた。ところが、状態遷移について殆ど知らなかったためソースコードを読んでも理解出来ず、ならば自分で実装してみようと作ったのがXhwlayになる。なので「再発明」はしておらず、「再実装」したのがXhwlayになる。
というわけで、「車輪の再発明」の良し悪しについては「再発明」と「再実装」に分けて考えるべきで、「再発明」の対象というのはアルゴリズムやデザインパターン、プロトコルなどの概念的なもの、「再実装」の対象はそれを実際に動かす為のソースコード、と考えると分かりやすいんじゃないかと思う。
アルゴリズムやデザインパターン、プロトコルなど概念的なものは、再発明するよりは洗練された先人のアイデアを拝借した方が良いと思う。
そしてそれがどう実現されているのか、それを学ぶにあたり、既製のライブラリを参考に自分で「再実装」するのは色んな面から決して無駄なことではないと思う。
現場の話をすれば、ライブラリがあってもライセンス的に使えなかったりして、やむなく「再実装」する場合もあるし。
というわけで、十把一纏めにして「車輪の再発明は無駄！」と切って捨ててしまうのは良くないと思うな、という話（結局ケースバイケース）。
余談：以前zip圧縮ファイルについての調べ物をまとめた事があるが(技術/歴史/zip,gzip,zlib,bzip2 - Glamenv-Septzen.net)、圧縮アルゴリズムの世界はライセンスや特許の影響が大きい為、再発明や再実装のカオスという感じがある。だがこの膨大な車輪の再発明・再実装の積み重ねのお陰で、多様かつ豊富な圧縮解凍ツールが作られたのだから・・・あ、それを言いだしたらUNIX系OSからしてそもそもが、再発明と再実装の積み重ねか！！
