ハンマーを持った人には何もかもが釘に見えるように、狂信者には何もかもが自分の肯定材料に見えるものだ。
歴史は繰り返すというが、同じ結果が同じ原因から起こるとは限らない。
ヘッドフォンがもうそろそろ限界のようだ。大体半年ぐらいもったのかな? いや、たった半年でぶっ壊れるのかよ。さすがは安物だな。ボーナス入ったことだし、次はもうちょっといいものを買おう。
どーでもいいけど、 UML がないとプログラムが書けないとか言ってる奴は (実際にいます、マジで) 頭がオカシイから病院にぶちこむのが得策だと割と本気で思う。何でそういう奴は頭オカシイと思うのかっつーと、 UML は OOP 言語でしか使えないからってのが最大の理由だな。きっと世の中は Java や C# だけで出来てると思ってるんだろ。
ところで UML に限った話ではないけど、結局プログラムを書くということはプログラミング言語のコードを書くことなんだから、プログラミング言語以外の何かで表現されたものはコードとはまったく別の抽象化レベルでなければならない (同じ抽象化レベルだったらコードを書いた方が早い)。そしてプログラミング言語のコードでさえ、抽象化の漏れや食い違いが問題になるというのに、決してマシンが実行できない表現媒体ではもっと酷い問題が起こるリスクってのは非常に高いと俺は思う。結局ソフトウェアの開発ってのは抽象化の階段を上がったり下がったりするもので、決して抽象度の高いところかバンジージャンプするものでも抽象度の低いところから登山するものでもないと思う。というかそれは、ひもつけないでバンジージャンプしたり近所の山に散歩するような気分でチョモランマにアタックしてるようなものだ。
最初にプログラムの外観だけを考えたときにはいけてると思っても、あとで中身を作っていったらダメダメだったということはよくある話だし、そしてそれは仕方がないのである (最初の大雑把なデザインが奇跡的に的を得ていても、プログラムへの要求が変化すれば当然そうなる)。じゃあ最初に UML でもなんでもいいけど、コードと (ある程度までは) 等価な設計書を書く意味って何なんだよ。確かに何かしら説明資料があった方がコードを読み解くヒントにはなるが、それはコードが出来てからの話だろう。
そしてそもそも UML がないとプログラムが書けないという言葉の裏には「誰かが UML を書いてくれる」という前提があるのだけど、俺はこのドキュメント担当者とコード担当者が分離してるのは頭の弱い発想だと思うのである。それはつまり二人が全く同じ対象の抽象化の階段を、完全に同期して上がったり下がったりしなければならないのだけど、それって無茶苦茶大変な事だろ。いまのところ俺は担当部分の詳細なドキュメントと実装の両方をやっているのだが、これは完全に正しい作業スタイルだと思っている。それの元になるもっと全体を俯瞰したドキュメントは別の人の担当だが、そっちに抜けがあったりこっちにミスがあるのは必然的な問題である。そしてこれは多分、開発手法みたいなもので解決出来る問題ではないという気がする。
話がえらいずれた。まあいいや、いつものことだ。飯買ってくる (今日は朝飯と昼飯が遅かったので今から晩飯)。
流石に外はかなり寒かった。俺は別に寒いのは好きじゃないが、家に入って暖房に安堵する感覚は好きである。同じ事は暑さにもいえるかもしれないが、俺は夏が嫌いなので。