適当に気になった技術や言語、思ったこと考えた事など。Tips設計のトップダウンコードが設計だとしても、全ての設計が不要になるわけではない。方眼紙に書いた誰も読まないコード書いた方が早い設計書ではない。機能設計までと名前空間(パッケージやディレクトリ構成)だ。何の事はない、機能ごとにパッケージを作りなさいという話だ。アプリを作る機会が多いので、例えばこんな感じになる。等)はっきり言えば、この時点では機能一覧みたいな感じだ。文章で言えば、「このアプリにある機能一覧」とか、本で言えば「目次」みたいなものだ。一つあまりにも複雑になりそうな場合は、メモ書き程度のクラス図、メッセージ図、シーケンス図や、ものによっては状態遷移図も書く。*1何故これしか書かないのかと言えば、それ以上の粒度で書いたとしても、(保守性も考慮して)なるだけシンプルに実装しようとすればどうしてもメソッドもクラスも増える。これ以上細かい粒度で書いた所で、ドキュメント保守という名の、生産性とは程遠いメンテナンス地獄が発生してしまう。設計のボトムアップ上記で既に半分述べてしまったが、機能を実現するためのコーディングを開始する。可読性を考えたり、コードをシンプルにしようとすると、メソッドが増えてくる。ログインであれば下記のような手続きがあるだろう。画面からのリクエストをバリデーションする該当するアカウントをテーブルから取得する取り出したハッシュ済みパスワードと、画面から入力されたパスワードを検証するログイン済みのセッションを作成する画面応答を作成して返すといった手順だろう。当たり前だが、これらは全部メソッド化すべきだ。一つのメソッドで記述すれば、処理の区切りを発見しづらくなる。追いづらくなり、変数を使っていればその寿命がわからなくなる。バリデーションにしても、各フィールドの定義、長さ、使用可能な文字などの設定もある。この定義とバリデーションの実行(リクエストからのデータの取得等)も分離するだろう。いった事を読みやすくしようと考えれば、当然ステップごとにメソッド化するだろう。一つのクラスにメソッドが増え過ぎれば、クラス分離を考える。バリデーションに関する定義クラスを分離するなどだ。適切な名前さえつけておけば、コードの意味が読み取りやすく、何かあっても十分に分離しているので、修正箇所は一箇所。それも他に影響を考えなくていい。クラスが増えれば、種類ごとにサブパッケージを考える。すると、当初からメソッドが増え、クラスが増え、パッケージが増える。それは可読性を上げるための手段であり、日本語で無理に書かれた仕様書より保守性を上げる手段だ。これは、設計からは見えてこない可読性に根ざした修正だ。ボトムアップでしか発生しない。トップダウンで全て流れるから、このボトムアップな設計は許容されないだろう。行超えの超大作なんかは、この仕様書メンテナンスコストを嫌うために発生しているものが多い。後戻り工数はそれくらい重い。