Life is beautiful

　iPhone用の「はてな人気エントリーリーダー」、そろそろ形になってきたのだが、作ってみていろいろと発見した部分もあったので、全面的にクラス構成を見直し、大幅に書き直した。

　HTTPで通信をしているコードが二カ所に分かれていたので、それをDataOverHTTP/XMLOverHTTPという二つのクラスにまとめ（XMLOverHTTPはDataOverHTTPのサブクラス）、はてな独自のRSSフィードを読んでいるコードから一般的なRSSフィードを扱うコードをくくりだしてRSSFeed/RSSFeedLoaderという二つのクラスにまとめて、あとで別のアプリケーションで再利用することを可能にした。それに加えて、各種ローダーに非同期通信をさせる主体をController（HotEntryViewController）からModel側（HateneHotEntry）に移すことにより、難解になりがちなControllerのコードを大幅に簡略化して読みやすくした。

　この手の「大幅書き直し」をリファクタリングと呼ぶ人もいるが、私にとってはこの手の書き直しはプロジェクトの初期においては日常茶飯事。「これで完璧」と思ったものを次の日にさらに大幅に書き直し、なんてことも良くある。どんなに賢いエンジニアであっても、最初に思いついたアーキテクチャが最適であるなんてことはまずあり得ないので、この「作っては壊す」段階はより良いアーキテクチャに到達するためには必須の工程。焼き上がった壷が気に入らずにたたき割る陶芸師と同じだ。

　この段階で目指すことは、とにかくメンテナンスのしやすいコードを生成すること。プロジェクトも後半になるとどうしても大規模な書き直しはしにくくなるため、その場しのぎのコードでプログラムはどんどんと「きたなく」なって行く。その時に大きく影響してくるのが、プロジェクトの前半で書いたコードの品質。基盤さえしっかりしていれば、「その場しのぎコード」が多少混ざったところでなんとかなる。基盤がぐらぐらしていると、デスマーチあるのみだ。

　NTTの研究所にいた時にかいま見たウォーターフォール型の開発は、上流にいるエンジニアがフローチャートのレベルまでに落とし込んだ詳細設計書を下請けに渡して「コード化」するというものだったが、ここで完全に欠如しているのは、この「作っては壊しながら設計を改良して行く」という工程。

　私の経験から自信を持って言えるのだが、どんなに優秀なエンジニアでも、この「作っては壊す」という過程を経ずには良いソフトウェアは作れない。料理でも陶磁器でも同じだが、ソフトウェアには「作ってみて初めて分かる」ことがたくさんあるので、そこからのフィードバックを主任設計者が自らコードを書いて実感することがとても大切なのだ。

　ソフトウェアを作る上でもっとも難しいのは、顧客や内部からのあいまいな要求を詳細設計書に落とし込む部分であることは誰でも知っている。しかし、意外にちゃんと認識されていないのは、良い詳細設計をするためには、実際に設計者自身が（ここが大切、他人に任せてはいけない）プロジェクト初期段階で、自分が考えた設計をコードに落とし込んで「作っては壊す」という作業を繰り返しながら（コードではなく）設計そのものを「練り上げて行く」過程が必須だということ。

　それはシェフが新しく思いついたレシピに基づいて実際に料理をしながらレシピを改良して行く過程、もしくは陶芸師が焼き上がった壷のできを見ながら製造工程を改良して行く過程と全く同じだ。実際に料理を作らずにおいしい料理のレシピが書けるシェフがいないのと同様に、実際にプログラムを書かずに品質の高い詳細設計書など書けるエンジニアがいるはずがない。