ちょこっとだけソースを触る機会に恵まれた。
仕様を頭に入れた上でソースを作る。
いいね。これ。


テストファーストでクラスを設計、構築してみた。
最小限の構成と、役割とやりたいことを記述したコメントで初めをつくる。
メソッドは外部とのやり取りを行う種類ごとにつくり、
似たような処理内容の扱いは内部で共通処理でも作って対処する。
必要となるパラメータはパラメータ用のクラスを作るか、クラスのプロパティを用意することで対処するようにし、
メソッドの引数に全部入れるなんてことをしない。
だってまだ完成形なんて見えてないもん。
データの流れと処理概要だけ用意して機能の構築の基礎をつくった。


その後。
関連する機能のクラスをつくり、データやパラメータ用のカタマリをつくり、
機能の分担を考え、調整し、
不都合があればガンガンリファクタリングを行い、
必要があればバンバンクラスを増やしていく。
( ´∀`)<ああ、しあわせ。


Excelと人とだけ格闘していた時間よりも、
ソースコードIDEと格闘している時間のほうが何倍も幸せだ。
だって仕様の確認を実装イメージで行い調整できるため、終焉に向けて進んでいることになるやん。*1


あやふやな結論を持って次には進めないのがプログラミング。
ゆえに、都度決定することは決定していかなきゃいけない。
あやふやな結論を持ってしても、なんとなく次に先送りできるのが仕様書作り。
ゆえに、あとでどうとでも取れるような表現があふれ返る。*2


そんな仕様書ってかドキュメントなんざ後回しでなーんの不都合も
ものづくり的にはねぇ!!っと実感している日々がありますよ。


ドキュメント作ってお客さん騙くらかして巨大なプロジェクトの体を成して何も作れないよりも、
3/4の予算でいいから初めにつけてくれたら同じ量のドキュメントもつけて完成物つくれるのになー
って思う。
順番かえるだけでえれぇ違い。
技術者のチカラでナンボでも変わるのがこの世界の成果なら、
あまった時間と人員をそっくりそのまま教育に当てればうまいことまわるはずなのになって
いまだに感じるところがある。*3
プログラミング万歳∩(゚Д゚)∩

*1:もちろん、この手法を実現するには要員のレベルが不可欠なのだが。

*2:んでもってプログラム作る人々につっこまれると。

*3:この障害最大の難関は人月の工数と人材派遣業だな。