ランディングポイントと精神衛生

ある機能を実装するときに、「これもできたらいいな」「あれもできたらいいな」というものがどんどん浮かんでくることがあると思います。それはそれで大変結構な話なんですが、それら全ての機能を実装しようと、あれこれ全てを詰め込んだプログラムを書こうとついつい大きなフレームワークを作成してしまうことがあります。これは、余りよくない状態です。
まずは、ビルドが通るまでに時間がかかるという点、そして、思いついた設計で本当に破綻なく全体が構築されるのかの確証を持ちにくい点、そして、正しく動作するまでに時間がかかるという点、そして、新しいＡＰＩや技術等のテストをそこに含めようとしている場合、上記のステップのどこかで何か問題が発生した時に、原因の切り出しに時間がかかるという点、にあります。
なので、もし自分の事前把握能力を超えたサイズの設計を一気に作りこもうとしていることに気づいた場合、私はその大きな設計を、複数の段階に分割するようにしています。分割の基準は、長くても2,3日、可能なら１日で実装できること、少なくともビルドだけでも通る状態がひとつのサイクルとなるような感じです。１日ビルドが通らない状態で仕事を終えるのって、ものすごくストレスが溜まりますし、もし根本的に設計が通らないことに気づいた場合の精神的時間的ダメージも大きいです。そして、例えば１週間経ってもまだ正常に動いていない状態で、何か良く分からない状態に陥ってしまった場合、問題がどこにあるのかを調べるコストが半端ではありません。それなら、途中に何度か中継点を作って、その段階で動作を確認しつつ、じわじわと次の状態へと持っていく方がよっぽど安心です。
と、最近先輩からXP(eXtreme Programming)の本を借りて読んだのですが、わりとそれに似た話が載っていましたね。ストーリーの作成、タスクカードの作成、テスト等。
XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法
とにかくビルドを通してランディングポイントを作成すること、これがわりと精神的に健全に開発を進めるコツかな、と思います。もちろん設計を分割することにより、「理想的な設計と実装で一発で完成に持っていけた場合」に比べてある程度ロスは発生すると思いますが、途中で何がなんだか分からず無間地獄にはまる恐怖となら、私はロスを選択します。それに、途中途中の段階で現在地点とゴールとのズレを確認することで、新たな状況の変化に対して設計も有機的に変えて行けますからね。自分に取って未知の領域が多いほどそういうこと(ゴールが変化していくこと)はよくある事ですし。