(sponsor Ad）
May 10, 2008
「F's Garage：ソースコードは一期一会の精神で書くべし。」のエントリーは僕としても書いた後で、いろいろ思うことがあったが、「一期一会」という言葉には多少こだわりがあります。
以下に書く話は、前回のエントリーを書いたときとは全然違うことを思って書いているので、矛盾が起きるかもしれません。ただ、以下の件を思い出したので書いてみます。
結構、僕にとって衝撃だったのが先日PDFが公開されていたサウンドハウスの情報漏洩の件でした。
↑のリンクで公開されている情報漏洩に関するプロセスが書かれたPDFは皆さん読まれたでしょうか？
全然事情は知らないので、以下は妄想ではありますが、一度動き出したシステムが、さまざまな理由やビジネス判断で修復をするチャンスを得られなかったのかなぁと思うと、非常に寂しく思っています。
いろんなツッコミ所はあって批判するのは簡単なんですが、やっぱり、どうにかできないものか？と考えています。
システムはActiveServerPagesで、きっと古いシステムだろうから、場合によってはまだSQLインジェクションという言葉も出ていなかった時代のころなのかなと思うので、まだ、SQLインジェクション対策なんて当たり前だと思っている人と、そうでない人の両方がいてしかるべき時代に作られた可能性もあります。
それはそれとしても、いろんな事情で最初に作った人と運営者とは別れてしまって、後々の運用がいろんな会社になったりして、根本のソースコードを触る人は誰もいない、というのは往々にしてあることです。
関わる業者が変われば、後から関わる業者は、できるだけ元のソースコードは触りたくないものだし、同じ会社がメンテしていたとしても、お金が流れなければ修復するチャンスはないですし、当時の担当者が退職していたりすると、もうそのソースコードは触らないことが一番リスクが低いというケースもあります。
機能追加するケースも、改築ではなく、増築するカタチでできるだけ元のソースコードには触らないというのは割とありうることだと思います。それが自社だろうが受託だろうが。
だからよくある話として、業者が変わるとできるだけ新規で作りたがろうとします。しかし、ECにおいて一回ビジネスが回り出しているシステムを止めたり新規システムに入れ替えるのは、ビジネスのリスクが伴います。特にSEO対策も含めるとURLを変えたくないハズです。新規にしたらgoogleからの訪問者が減ってしまいましたということを許容するためには、相応の理由が必要ですが、それを提案して納得できるケースは少ないでしょう。
さまざまな事情でメンテナンスしにくい状況に追い込まれたソースコードは、もはやリファクタリングされることはありません。
つまりソースコードは適切に管理されるハズというのも、またなんとも言い難い現実があると言うことだと思っています。（オープンソースもそうですね。）
また、もう何年も運用されているシステムで、奥底に埋め込まれてしまって、いろんなところから参照されているユーティリティなどで「ここはもう誰もいじれない」と思うのは、全くないと言えるでしょうか？
僕も自分のエントリーを書いた後で、あ、これって、だからテストいらねーとか言ってるのアホじゃん、と自分の発言と行動について振り返るチャンスに恵まれ、だからこそユニットテストとリファクタリングを両立するように物作りすべきというのはやっても良いよねとは、確かに思いました。プログラマの視界範囲ではね。
しかし、さまざまな事情で、もう誰にも面倒を見られることなく運用だけされ続けるケースもありうると思います。だからこそ、今の日本のWebシステムにおいて、SQLインジェクションの被害が頻発していると言っても決して過言ではないと思っています。
だから、どんなに仕事の状況に問題があるケースだったとしても、プログラマはプロとしての誇りを持って、そのときにできる限り良いコードを書いて欲しい。もうそのソースコードがメンテナンスされなくなっても問題ないソースコードを書けるようになって欲しい。それは切実な願いでもあります。
（別に情報漏洩をプログラマのせいにしているわけではありません。さまざまな不幸の中の一つということです。）
あと第一、リファクタリングは低いコード品質を正当化するものではありません。リファクタリングなんて言葉を使える人がやってることは、そもそも悪くない物を、より良い物に改善するプロセスだと思っています。
だから、リファクタリングについて主張される方と比べると、多分、僕が言ってることはもっと低い次元の話だと思っていますが、正論ではなく、そういう現実は絶対に存在しているという確信もまたあります。別にそんなことを納得されても、ちっともうれしくもない話ではありますが。