ICONIXプロセスでは、コードを書く視点を次の四つに分けている。
・コードという世界に閉じた視点
・設計と実装の同期という視点
・ユースケースとの同期という視点(ユースケースの実現という視点)
・ドメインモデルの実現という視点
コードを書くときも、コードをレビューする時も三つの視点がある。どれも必要...
コードという世界に閉じた視点
コードレビューで言えば、コーディング規約、コードスタイル、命名(の形式的な)規約とかをチェックする視点ですね。
いろいろ好みというか思想というか、意見が分かれるところですね。
「コードコンプリート」では、プログラマー気質として議論していたかな。
この世界がなくなるわけではないけど、役に立つソフトウェアを作る、理解が容易で、変更がやりやすいコードにする、という目的のためには、この視点は視野が狭すぎる。
どんなソフトウェアが価値があるかは、コードの外の世界からやってくる。役に立つソフトウェアかどうか判断するのは、コードの外の世界の人たち。
変更要求も、コードの外の世界からやってくる。直すのはコードだけど、なぜ直すのか、どう直すべきかの理由は、コードの外にある。
だから、コードの外の視点を重視すべき。
設計と実装の同期という視点
ICONIXプロセスでは、シーケンス図と詳細クラス図で設計を詳細に完成させる。そして、コードは可能な限り詳細設計から自動生成することを重視する。
設計自体は、より上流の分析設計から導き出しているので、設計とコードを徹底的に同期すれば、役に立つソフトウェアを実現できるし、設計時に可能な限りプレファクタリングしてあるので、変更にも強いソフトウェアになっている(はず)。
最低限、この設計と同期という視点でいつもコードを書き、レビューすることが必要。
ユースケースの実現という視点
ICONIXプロセスが最も強調している視点。
ユースケース記述を元に、ロバストネス図を描いて、それを元にシーケンス図を描きながら、詳細クラス図を完成させる。その設計結果から、コードを自動的・機械的に生成する。
ユースケース記述をそのままコードに落とし込み、ユースケースを実現したソフトウェアを作ることを強調している。
ロバストネス図でもシーケンス図でも、必ずユースケース記述を貼り付け、ユースケースのステップをひとつずつ絵にしながら、実装方法まで落としていく。
予備設計のレビューも、詳細設計のレビューも、コードのレビューも、いつも、ユースケースとの同期をチェックする。
このやり方を徹底すれば、確かに役に立つソフトウェアの開発に直結しますね。
しかし、理解が容易で変更がやりやすいソフトウェアになる保障はない。
ドメインモデルの実現という視点
ICONIXプロセスの基本の流れはユースケースをコードで実現する手順。
しかし、同時に大きな流れとして、ドメインモデル(用語集)から出発して、詳細クラス図にして、最後はコードに落とし込む流れが基本構造になっている。
コードは、ユースケース側の動的(振る舞い)の流れではなく、ドメインモデル側の静的(構造)の流れの成果物ですね。
これはユースケース駆動だと言っているICONIXプロセスのある種のトリックだと思う。
あまりガイドブックでは強調していないが
・ドメインの構造は比較的安定している
・その安定構造を元にソフトウェアを設計しておくと、変更に強い
という思想、価値観を明確に持っている。
これって、ドメイン駆動設計と同じ価値観ですよね。
ICONIXプロセスは、動的モデルと静的モデルをいつも見比べて、整合性を取ることを重視している。
振る舞いと構造でバランスを取る、という言い方ができるかもしれない。
だから、静的モデルの最終形のコードは、ユーザの要求を具体的に表したユースケースモデルと一致する。
これが ICONIXプロセスの特徴だし、実践してみて、効果に手ごたえを感じているところです。
---
コードを書くときに、コードに閉じた世界ではなく、ソフトウェア開発の出発点のドメインモデル(問題領域の用語集)とユースケースモデル(使い方のシナリオ)をいつも意識する。実践手順として、それが自然にできるようにする。
そうすることで、役に立つソフトウェア、読みやすいコード、変更が安全にできるソフトウェアを、確実に楽に作ることができる。
・コードという世界に閉じた視点
・設計と実装の同期という視点
・ユースケースとの同期という視点(ユースケースの実現という視点)
・ドメインモデルの実現という視点
コードを書くときも、コードをレビューする時も三つの視点がある。どれも必要...
コードという世界に閉じた視点
コードレビューで言えば、コーディング規約、コードスタイル、命名(の形式的な)規約とかをチェックする視点ですね。
いろいろ好みというか思想というか、意見が分かれるところですね。
「コードコンプリート」では、プログラマー気質として議論していたかな。
この世界がなくなるわけではないけど、役に立つソフトウェアを作る、理解が容易で、変更がやりやすいコードにする、という目的のためには、この視点は視野が狭すぎる。
どんなソフトウェアが価値があるかは、コードの外の世界からやってくる。役に立つソフトウェアかどうか判断するのは、コードの外の世界の人たち。
変更要求も、コードの外の世界からやってくる。直すのはコードだけど、なぜ直すのか、どう直すべきかの理由は、コードの外にある。
だから、コードの外の視点を重視すべき。
設計と実装の同期という視点
ICONIXプロセスでは、シーケンス図と詳細クラス図で設計を詳細に完成させる。そして、コードは可能な限り詳細設計から自動生成することを重視する。
設計自体は、より上流の分析設計から導き出しているので、設計とコードを徹底的に同期すれば、役に立つソフトウェアを実現できるし、設計時に可能な限りプレファクタリングしてあるので、変更にも強いソフトウェアになっている(はず)。
最低限、この設計と同期という視点でいつもコードを書き、レビューすることが必要。
ユースケースの実現という視点
ICONIXプロセスが最も強調している視点。
ユースケース記述を元に、ロバストネス図を描いて、それを元にシーケンス図を描きながら、詳細クラス図を完成させる。その設計結果から、コードを自動的・機械的に生成する。
ユースケース記述をそのままコードに落とし込み、ユースケースを実現したソフトウェアを作ることを強調している。
ロバストネス図でもシーケンス図でも、必ずユースケース記述を貼り付け、ユースケースのステップをひとつずつ絵にしながら、実装方法まで落としていく。
予備設計のレビューも、詳細設計のレビューも、コードのレビューも、いつも、ユースケースとの同期をチェックする。
このやり方を徹底すれば、確かに役に立つソフトウェアの開発に直結しますね。
しかし、理解が容易で変更がやりやすいソフトウェアになる保障はない。
ドメインモデルの実現という視点
ICONIXプロセスの基本の流れはユースケースをコードで実現する手順。
しかし、同時に大きな流れとして、ドメインモデル(用語集)から出発して、詳細クラス図にして、最後はコードに落とし込む流れが基本構造になっている。
コードは、ユースケース側の動的(振る舞い)の流れではなく、ドメインモデル側の静的(構造)の流れの成果物ですね。
これはユースケース駆動だと言っているICONIXプロセスのある種のトリックだと思う。
あまりガイドブックでは強調していないが
・ドメインの構造は比較的安定している
・その安定構造を元にソフトウェアを設計しておくと、変更に強い
という思想、価値観を明確に持っている。
これって、ドメイン駆動設計と同じ価値観ですよね。
ICONIXプロセスは、動的モデルと静的モデルをいつも見比べて、整合性を取ることを重視している。
振る舞いと構造でバランスを取る、という言い方ができるかもしれない。
だから、静的モデルの最終形のコードは、ユーザの要求を具体的に表したユースケースモデルと一致する。
これが ICONIXプロセスの特徴だし、実践してみて、効果に手ごたえを感じているところです。
---
コードを書くときに、コードに閉じた世界ではなく、ソフトウェア開発の出発点のドメインモデル(問題領域の用語集)とユースケースモデル(使い方のシナリオ)をいつも意識する。実践手順として、それが自然にできるようにする。
そうすることで、役に立つソフトウェア、読みやすいコード、変更が安全にできるソフトウェアを、確実に楽に作ることができる。