忍耐力指向プログラミング (Patience Oriented Programming) #47

公開日: 2013-03-18


先日、宮川さんのpodcastに登場させてもらったときに [1] 忍耐力思考プログラミング (Patience Oriented Programming) の話を少しだけした。プログラミングで重要な能力のひとつに忍耐力というものがあるのではないかと、といった話だ。

Perl の開発者である Larry Wall がプログラマの三大美徳として無精 (Laziness)、短気 (Inpatient)、傲慢 (Hubris) を挙げていて、忍耐 (Patient) が大事というのは、二番目の Inpatient と真っ向から対立する。なぜ短気がよいかというと Larry Wall によれば、コンピュータが怠けているときに感じる怒りがよいプログラムを書くことにつながるとのこと。これはごもっともだと思う。

忍耐力指向プログラミングでの忍耐力とは、コンピュータが怠けているときに我慢する、というのではなく、ソフトウェア開発で発生する、ありとあらゆる(往々にしてくだらない)問題に屈しない、という意味での忍耐力だ。

先日、知人のプログラマがこんな話をしていた。いわく、とあるアプリで音を鳴らす機能を作ろうとしたところ大変な yak shaving [3] に巻き込まれたとのこと。

というのも、音を鳴らすためのコードは既に存在するのだが、そのクラスのオブジェクトがプログラムの中で非常に奥まったところに存在していて、自分のコードからはそのままでは使えない。こいつを使うためには、どうにかしてそのオブジェクトへのアクセスを確保する必要があり、いろんなところに配管を通さないといけない。

で、なんとかその配管作業を終わらせて使おうと思ったら、 MP3 フォーマットをサポートしていない。じゃあどうやるかというと、どうも ffmpeg というライブラリを使って変換してやればいいらしい。ffmpeg はいろいろなことができるが使い方が難しく、 MP3 をデコードするコードを書くのに苦労してしまった。

これでOKかと思えば、プロジェクトのセキュリティ上の方針で、メインのプロセスの中では ffmpeg は使ってはいけないという。がんばって書いたコードは無駄になってしまった。じゃあまあ MP3 はとりあえずあきらめて、生の音データでとりあえず進めようとと思ったら、今度は音関連のコードへの依存関係に問題が発生して、その辺を解決しないといけないことがわかった。さらに、最初に着手した配管作業もやり方が悪いんじゃないかと、他のエンジニアから反対されているという。

「そんなわけで、なかなか進まないんですよ!」といって氏は笑っていた。これはなかなかの忍耐力指向プログラミングだ。これだけ yak shaving にぶちあたっても笑っているのだから、彼の忍耐力はかなり高い。

音を鳴らすなんてことは本来なら簡単にできそうなものだが、規模の大きいソフトウェアだといろいろとややこしい事情があって、難しくなってしまうようだ。既存のコードは彼の新しいユースケースのことなんて考えられていないし、そもそも将来のユースケースを完全に予測してソフトウェアを設計することは不可能だ。蓄積された技術的負債 [4] も前進を阻む。

前回の「VPNの謎」で登場したバイセクト(2分探索による問題の特定)も忍耐力指向プログラミングだ。1ターンにかかる時間が短ければ、そんなに苦ではないが、ビルドとバグの再現に要する手間が多いと、バイセクトだけで一日が終わってしまうこともある。

複雑性に対するチャレンジも忍耐力指向プログラミングになりうる。複数のシステムが協調しながら動く巨大なクラウドサービスに何か込み入った機能を追加しようとする。いくつものシステムに変更を入れるは大変な仕事で、それだけでも気が滅入るが、全体のシステムが複雑だと、そもそも全体を動かしてテストするのが難しかったりする。

全体のシステムが end-to-end で動くように、すべてのサブシステムを正しく設定して、正しい順序で起動する。一箇所でも手順が間違っていると、システムは起動しないか、あるいは、変なモードに入ってしまい、正しく動かない。このセットアップの時点でハードルが高いとコードを書く以前のところで行き詰まってしまう。コードを書く前に燃え尽きてしまいそうだ。

バッドノウハウ [5] も忍耐力指向プログラミングが発生しやすい領域だ。最近のブラウザでは簡単にできることが、一昔前のブラウザではどうしてもうまくいかなかったりする。この互換性の問題を解決するために膨大なハックとバッドノウハウが必要で、忍耐力を消耗する。

などなど。書いていてだんだん気分が暗くなってきてしまった。理想的な世界ではこういう問題は存在しなくて、もっと本質的な作業に時間を使いたいところなんだけど、現実の世界では、ありとあらゆる厄介ごとが降ってきて、前進を阻まれてしまう。

こういった、ものすごい yak shaving やら、バイセクトやら、複雑性やら、バッドノウハウやら、それらの複合体やらを克服して、その上ですごいものを作っているプログラマを目の当たりにすると、尊敬の念を禁じ得ないのであった。

[1] http://podcast.bulknews.net/post/44649386760/ep4
[2] http://ja.wikipedia.org/wiki/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9E#.E3.83.97.E3.83.AD.E3.82.B0.E3.83.A9.E3.83.9E.E3.81.AE.E4.B8.89.E5.A4.A7.E7.BE.8E.E5.BE.B3
[3] http://0xcc.net/blog/archives/000196.html
[4] http://ja.wikipedia.org/wiki/%E6%8A%80%E8%A1%93%E7%9A%84%E8%B2%A0%E5%82%B5
[5] http://0xcc.net/misc/bad-knowhow.html

Satoru Takabayashi