■

最近すっかり「詳細設計」の作業をやっている。
ドキュメント作成。
Struts使った画面機能の設計。

とりあえず始めはベッタベタに処理ってかやることを書いてみた。
昔よく見た「仕様書」のようなめちゃくちゃな文章になった。
「〜の場合」「〜の時」「〜だったなら」とか条件分岐が多く、
これを１メソッドに書かれたらクサレソースだなこりゃと思った。

こりゃいかんと思い、別の形式を模索してみた。
現在ソースコードを記述している人に現状のソース構成を聞き、見せてもらいなにがどーなりゃこーなるってのを教えてもろた。
ほかの設計者が言った経験からでた言葉がある
「設計書からそのまま落とせるようなレベルで無いと質問攻めにあうんですよ。思う通りに解釈なんてしてくれないんですよ」
これもこれで納得できることなのでそれもふまえて。

記述レベルを考慮し、いろいろごちゃごちゃ書かないためにあれこれ考えていたら、
いつもソース作る時に考えていることとにたよーなことだと気がついた。
シンプルな設計、シンプルな機能。その集合体。
設計書１枚をメソッドに見立てて機能ってか役割分担を決めてから書き出してみた。
(..ﾟДﾟ)＜えれぇ書きやすいぞ

さすがソースコードイメージ。ソースコードを書くかのように作れる。
しかし枚数が増えたｗ
もともとは１メソッド分２枚。内容複雑ってのが、
４メソッド分４枚。それぞれ内容がシンプル。
シンプルなので量産が効くっておまけつき。
設計書の中でインデントウェーブみたいな事になっていたのが無くなったらスッキリした。

しかし重要な問題点があった。
この構成で書いていけるにしても、
こう書けるやつは実は少ないっと指摘された。
・・・・・・
(..´Д｀)＜難儀な話だ。

処理の流れを把握し、それぞれの役割分担を踏まえた上で、それぞれの役割を定義する。
とりあえず、今の仕組みの中で出来ることをやってみたら、
書類もソースも作り方に差異は無いってことを実感できた。
記述の仕方が違うだけ〜〜　かな？