目的を決めよう |
||
|
このままでは難しすぎる |
||
|
ひとたび開発がスタートしたら、開発者の最終目的は「完成」です。開発工程のすべてのフェーズにおいて、ソフトウェアの完成に焦点があてられるべきです。 |
||
|
さて、開発工程の中で実際に製品が作られるのはどのフェーズでしょうか?そう、コーディングですね。出荷されるソフトウェアのすべては、コーディングの段階で作られます。この段階で、ソフトウェアの機能・品質・性能などのすべてが決まってしまいます。 |
||
|
品質がコーディングの段階で決定するのなら、出荷時に残るバグの数もコーディングで決まります。もちろん出荷時にバグが残っているという状況は好ましくありません。しかしソフトウェアの全てをコーディングのフェーズで作るということは、とても困難で難しいことです。いつもバグが多いのはプログラマの怠慢や能力不足ばかりが原因ではなく、そもそもコーディングというものが難しすぎるのです。その上、バグやユーザーからのクレームがたとえ設計に起因するものだとしても、修正するのはコーディングを行ったプログラマです。品質上の問題はプログラマが原因ではありません。もっと大きくて、基礎的な問題です。 |
||
だから、設計 |
||
|
「コーディングが難しすぎる」という問題を克服するためにできることのひとつが、設計です。うまい設計は、そのままでは困難だったり不可能だったいるする状況に希望をもたらします。どう考えても半年はかかる作業を3ヶ月で終わらせる方法をひねりだしたり、複雑で手の着けようがないように見える仕様を単純な部分に分割したりすることによってコーディングのリスクを軽減します。 |
||
|
ところで、仕様を決めたり設計をしたりしている段階では、まだ製品は作られません。ですからどんなに野心的な仕様を考えても、どんなに高度な設計をしてみても、それらをコーディングの段階に適用できなければ無意味なわけです。これは、設計はコーディングに適用したときに効果を発揮するようなものでなければならないということです。 |
||
|
--- 設計は、コーディングのためなり --- |
||
|
誤解されるといけないので断っておきますが、もちろんプログラマは腕を磨くべきです。いつまでも、どこまでも、絶え間なく! |
||
|
|
|
|
(「コーディングの向こう側」は2000年4月から2001年5月にかけて作成されたコンテンツです。)