プログラミングは「ブロックを組み合わせる」感覚に似ている

　若い開発者に僕が書いた設計書を説明後、プログラムをJSPから書き始めるのか、それともServletから書き始めるのか、聞いてきた。
　僕は、まずJSPを動かしてからServletを書いたら、と言ったら、コンパイルエラーばかりで全く進まない。
　僕の意図は、JSPやServletを確実に動かしながら、fakeした機能を一つずつ実装していけばいいだろ、ということだった。
　結局、若い開発者にValueObjectからボトムアップで書かせたら、コンパイルエラーもなくなり、ようやく書けた。

　プログラムを書く時、トップダウンから始めるか、それとも、ボトムアップから始めるか？
　ＰＧやＳＥなら一度は、はまった経験があると思う。

【１】プログラミングとは、機能を組み合わせていくこと

　ＩＴ業界に入った時、先輩から、「プログラマは数学者とは違った能力を要求される。機能を組み立てる感覚が大事だ」と言われた事がある。

　プログラミングとは、小さな部品(モジュール)を別の部品からコールして、メインプログラムを作っていくこと。
　その時に、データ構造とかアルゴリズムなどの数学的知識はあった方が良いが、それよりも、機能を実現するために、数多くのモジュールを組み合わせて整合性を合わせるのが大事。

　Perl関西で知り合ったプログラマが「Perlの面白さはCPANモジュールを組み合わせる所にあるんです」と言っていたのが印象的だった。

　これはまさにボトムアップからのプログラミングの感覚。

【２】テスト駆動ツールがあれば、トップダウンのプログラミングは可能

　ボトムアップのプログラミングで怖いのは、作った小さなモジュールが正しく動かないまま、メインプログラムを実装して動かないこと。

　でも、JUnitなどのテスト駆動ツールを使えば、モジュールが小さいほどテストしやすく、品質も良くなる。
　逆にテスト駆動ツールがあるならば、トップダウンでインターフェイスを定めながら、仕様が不明な機能はfakeしながら実装できる。

　ボトムアップのプログラミングの弱点は、細部にこだわりすぎて、実現する機能をインターフェイスとして考えられなくなること。
　テスト駆動ツールを使えば、その弱点を補うことが出来る。

【３】設計者はトップダウンで要求を仕様化していく

　設計者の仕事は、あやふやな要求を仕様として落としていくことにある。
　つまり、要求から大まかな機能を洗い出し、その整合性を取りながら、機能を矛盾なく実現できるレベルまで細分化していく。

　設計者の頭の中では、機能をInputとOutputのペアで考え、ひたすらそのペアの連鎖で全ての機能が矛盾なく動くか、ロジックを組み立てる。
　つまり、どう実現するかというHowよりも、何を実現するかというWhatを重視している。

　そして設計手法は、自然にオブジェクト指向設計になる。
　機能をオブジェクトに見立てて、メッセージを送ったら、自分が何をするか知っているから期待した結果を返す。
　そのオブジェクトを整合性を保持したまま協調動作できるか？という考えをずっと突き進めるだけ。
　これは、トップダウンで仕様を煮詰めていき、最終的にインターフェイスを決めるまで突き進めることと同じ。

　オブジェクト指向設計の良い所は、メッセージ送信という発想によってInputとOutputの関係だけに注力できることと、実現できるかどうかというHowの部分をカプセル化して設計を先に進めることができること。

　トップダウン設計では、要求から仕様へ落とし、最終的にはクラス図へ落とす。その時点で、ほぼ設計は出来上がる。
　クラス図ができれば、実装は単なる機械的作業にすぎない。

【４】WhyとWhatとHowの関係

　Howを考えるのは、実装であり、プログラマのお仕事。
　Whatを考えるのは、仕様であり、ＳＥのお仕事。

　Whatを洗い出す時、要求の理由や背景を考えた方が良い時がある。
　つまり、何故そんな機能が必要なのか、をぶつけていくと、そもそもそんな機能は必要ではなかったとか、実は別の本質的な機能が必要だった、ということもありうる。

　要件定義とは、Whatで考えるために、Whyをどれだけお客から引き出せるか、という技術を要求しているのだろう。

【５】プログラミングの楽しさはモジュールの組み立てにある

　プログラミングの楽しさは、少年時代に積み木やブロックで好きなように組み立てた経験に似ている。
　そして、その組み立てた物は、実はすごく脆い。
　ほんの少しバランスが崩れただけで、全部壊れてしまう時だってある。
　その辺りのハラハラドキドキ感が楽しいのかもしれない。

　デスマーチではハラハラドキドキしたくないけどね(^^)