違うものは、区別しよう |
||
|
やるべきことと、やり方 |
||
|
コーディングをするときは、仕様を満たすことを目標にすると思います。もちろん仕様は変わることもあるけれど、今まさに作っている最中というときにはやはり仕様を満たすことを考えているでしょう。決定した以上、仕様は絶対です。 |
||
|
しかしご存じのように、仕様を満たすのは大変なことです。なぜでしょう?コーディングは難しいという話を以前にしましたが、理由はそれだけではありません。現実のコーディングは、あまりに仕様からかけ離れているのです。何も考えずに作ってしまうと仕様の通りに作るのは大変な作業になります。この、あまりにかけ離れた2つをつなぎ合わせるためには、そのことを意識した設計をしなければなりません。 |
||
|
もちろん設計は仕様ではないので、満たすべき必要事項を記述したものではありません。仕様は満たさなければなりませんが、設計はそうではありません。設計を行うのは、コーディングによって仕様を効率的に実現するためであり、いわば、ガイドラインです。仕様・設計・コーディングは明確に区別されなければなりません。 |
||
|
--- 設計は、仕様と実装をつなぐガイドラインなり --- |
||
|
例えば、仕様は利用者が理解しやすい形式で書かれているでしょう。その中には業務上の特殊な事情や例外的な状況に関連するものが多いかもしれません。それらをそのままの形でコーディングするのは効率的ではないので、より一般的な条件を考えることによって例外事項を通常処理と同様に扱うようにし、作業量を減らすようにします。そういうやり方をひねり出すのは設計の時です。そうすることによってコーディングが楽になるし、バグも減るでしょう(開発する量が減れば、その分バグも減るはずです)。 |
||
気を配るべきこと |
||
|
実際に品質や機能が実現されるのはコーディングの時なので、設計はコーディング上の自由を奪うものであってはなりません。設計者はデータ構造やモジュール構成などの大まかな部分だけを定めるようにし、作り方に関する細かい部分はプログラマに任せなければなりません。「ファイルの何バイト目にどのデータを格納するか」とか、「この関数の戻り値の型は何であるか」などといった細かいことを設計者が言ってはいけません(「このファイルには○○の情報を納める」とか「このモジュールの役割は○○である」などで十分です)。ましてや、コーディングを困難にするような設計は絶対にあってはなりません。 |
||
|
もうひとつ、あってはならない(しかし実際にはよくある)ことがあります。それは、仕様と設計を混同することです。仕様は満たすべき機能を記述したものであり、設計はそれをどうやって作るかということです。作り方を仕様に含めてはいけません。 |
||
|
|
|
|
(「コーディングの向こう側」は2000年4月から2001年5月にかけて作成されたコンテンツです。)