設計はトップダウンとボトムアップ
設計のトップダウン
コードが設計だとしても、全ての設計が不要になるわけではない。
もちろん、Excel 方眼紙に書いた誰も読まないコード書いた方が早い設計書ではない。
まずは機能設計までと名前空間（パッケージやディレクトリ構成）だ。
何の事はない、機能ごとにパッケージを作りなさいという話だ。
私は MVC 形状の Web アプリを作る機会が多いので、例えばこんな感じになる。
- root
- （処理の種類、controllers, models, entities, utils 等）
- （機能カテゴリ名、account, administrators）
- （機能名、login, logout, signup 等）
- （機能カテゴリ名、account, administrators）
- （処理の種類、controllers, models, entities, utils 等）
はっきり言えば、この時点では機能一覧みたいな感じだ。
文章で言えば、「このアプリにある機能一覧」とか、本で言えば「目次」みたいなものだ。
もう一つあまりにも複雑になりそうな場合は、メモ書き程度のクラス図、メッセージ図、シーケンス図や、ものによっては状態遷移図も書く。*1
何故これしか書かないのかと言えば、それ以上の粒度で書いたとしても、（保守性も考慮して）なるだけシンプルに実装しようとすればどうしてもメソッドもクラスも増える。
つまり、これ以上細かい粒度で書いた所で、ドキュメント保守という名の、生産性とは程遠いメンテナンス地獄が発生してしまう。
設計のボトムアップ
上記で既に半分述べてしまったが、機能を実現するためのコーディングを開始する。
しかし、可読性を考えたり、コードをシンプルにしようとすると、メソッドが増えてくる。
例えば、ログインであれば下記のような手続きがあるだろう。
- 画面からのリクエストをバリデーションする
- 該当するアカウントをテーブルから取得する
- 取り出したハッシュ済みパスワードと、画面から入力されたパスワードを検証する
- ログイン済みのセッションを作成する
- 画面応答を作成して返す
といった手順だろう。
当たり前だが、これらは全部メソッド化すべきだ。
何故なら、一つのメソッドで記述すれば、処理の区切りを発見しづらくなる。
つまり追いづらくなり、変数を使っていればその寿命がわからなくなる。
バリデーションにしても、各フィールドの定義、長さ、使用可能な文字などの設定もある。
当然この定義とバリデーションの実行（リクエストからのデータの取得等）も分離するだろう。
そういった事を読みやすくしようと考えれば、当然ステップごとにメソッド化するだろう。
一つのクラスにメソッドが増え過ぎれば、クラス分離を考える。
例えばバリデーションに関する定義クラスを分離するなどだ。
適切な名前さえつけておけば、コードの意味が読み取りやすく、何かあっても十分に分離しているので、修正箇所は一箇所。
それも他に影響を考えなくていい。
クラスが増えれば、種類ごとにサブパッケージを考える。
すると、当初からメソッドが増え、クラスが増え、パッケージが増える。
それは可読性を上げるための手段であり、日本語で無理に書かれた仕様書より保守性を上げる手段だ。
しかもこれは、設計からは見えてこない可読性に根ざした修正だ。つまりボトムアップでしか発生しない。
WF の限界
WF ではトップダウンで全て流れるから、このボトムアップな設計は許容されないだろう。
WF あるあるの 1 メソッド 100 行超えの超大作なんかは、この仕様書メンテナンスコストを嫌うために発生しているものが多い。
WF の後戻り工数はそれくらい重い。
（もしくは設計通りに作れという政治的な圧力があるか、開発者から考える頭が欠如してしまったかだ）
この辺りが WF という手法の限界だ。
ここまで予測できるのなら WF もありだろう。
だが、C言語がメモリリークやポインタ操作ミスでクラッシュを招くように、C言語はプログラマに全能性を求めてしまっている。
同様に、WF の流れは設計者に全能を求めてしまう。
その他考えてる事
Martin Fowler 氏に言わせれば、 コードはドキュメントである ということだ。
この論文では、作成したものを表現するという点に関して、ソースコードは、その実現方法を含む完全な形で全てが記載されているという点があげられる。
また、この文章の中に、「コードは設計である」 という話もある。
ここで WF の設計を考えると、その設計はそのままコードに置き換えられるか？不可能だ。
なぜなら、そこまでできる位なら、設計書をコンパイルした方が圧倒的に効率的だ。
そう考えて、かつて富士通は限定的とは言え 設計書をコンパイルして実行できるようにする 試みもしている。
現実的に広まったかは別として、面白い観点だ。
だがそれを WF の定義で見て設計と呼ぶのか？コンパイルして実行できるものを書く行為が？
結局の所、 コードを書くことと設計する事に差はほぼないという事だ 。
むしろ、エネルギーも「熱→水蒸気→（タービンにかけて）電気」と変換する上でエネルギーをロスするように、工程を増やして他人を介在すれば、それだけ原型の仕様が失われる。
そこを考えれば、設計/製造と分けることが現実と乖離していることがわかる。*2
