2012/02/08

書かれなかったもの

プログラマへの誤解 | pineapple blog

プログラムを書かない人がプログラムを読んだときにする良くある間違いは，ああこんなプログラムなら自分にも書けそうだと思うことだ．プログラムは何百万とある可能性からたったひとつ（は言い過ぎにしてもわずかながら）の正しい方法を残したものであり，この捨てる能力こそがプログラマの実力だから．

ああ、以前『引き算の技術』というのを書いたことがあったけど、上に引用した文の方がずっと的確でかつ具体的だなあ。

「たったひとつの可能性を選び取って残りは捨てる」とだけ言うとわりと何にでも適用できる概念のようだけど、ことプログラミングに関しては、「本当に捨てる」ことは珍しくない。つまり、実際にいくつも作ってみて、ベンチマークを取ったりしばらく実際に使ってみたりして、ベストと思えるものだけを残す。捨てられたものはバージョン管理システムのブランチくらいにしか残っておらず、ソースを見ても何が捨てられたのかはわからない。

経験を積めばいちいち書かなくても見当をつけて選択肢を枝刈りできるけれど、経験者が散々議論してもアイディアが3つくらいに絞られた時点で「あとは実装してベンチとらないと何とも言えないね」ってなることはよくある。しかも、大抵一番難しいのは実装すること自体ではなくて、実装間の比較をうまく行えるような環境を作ることの方だ。(逆に、比較のためのフレームワークがちゃんと出来ていると、がんがん実装を試せるので進化がとても速くなる)。で、完成品のソースコードにはそういう実験のための環境ってのはやっぱり含まれてない。

人が作ったものを見て、ぱっと「なんかうまくないなあ、こうすればいいのに」って思うことはよくあるけど、自分も同じものを作って試してみた経験が無い限り、一旦立ち止まって考えるようにしている。こうすればいいのに、っていう他の方法は既に試し尽くして、うまくいかなかったから今の方法になってるのかもしれない。

(もっとも「他の方法は試してみてダメだった」ってことがわかっててもやっぱり今の方法はダメだ、って場合があるからややこしい。つまり、試しかたがダメだった、ということである。)

(追記2012/02/09 06:41:08 UTC): ソフトは一度リリースしたら完成ってもんじゃなく、むしろ生物のように新陳代謝しながら生きながらえてゆくので、一度本体から捨てたものでも将来のために取っておきたい、ということはある。将来の人が同じ轍を踏まないためにも、また将来条件が変わって捨てた選択肢が復活するという可能性のためにも。

自分は、コードそのものは可能ならブランチに取っておいて、ベンチマーク結果や実験の概略などはパブリックなものならWiLiKi等に、仕事上のものはイシュートラッカ等に残すようには心がけている。多分重要なのはレポートの方で、コードはメンテしない限り本体の進歩からすぐに取り残されてしまうので、歴史的な資料価値しかないだろう。レポートの方はちゃんと書いておけば、将来アイディアをまた試したい時に大いに参考になる。ちゃんと書くのは手間がかかって大変なんだけれど。

そんなわけで、「紆余曲折色々試してこうなりました」っていう紆余曲折の部分が書いてある論文は読んでて面白い。プロジェクトのpost mortemリポートとかも。

Tag: Programming