仕様と実装

世の中の多くの人にとっては，「実装（implementation）」という言葉はなじみのないものなのだろう。それと並べて使われる「仕様（specification）」という言葉もなじみのないものなのだろう。

とはいうものの，私も，この言葉の意味を理解したのは，1992年から1993年にかけて，米国のとある大学に在籍していたときだったように思う。つまり，日本で，文系の大学の学部に通って，ちょこちょこっとプログラムを書いているくらいでは，そんな言葉はなじみがなかったのだ。

言葉の威力というものですね。その言葉を知っているかどうかで，きっちり考えられるかどうかが決まってしまうのだから。

仕様は，あるべき姿である。実装は，実際の姿である。一つの仕様に対して，複数の実装がありうる。通常は，仕様が決まってから実装をするのだが，実装不可能な仕様を決めても意味がないので，実装をまったく考えずに仕様を決めてはいけない。実装が既にあって，そこから，本質的な部分を仕様にするということもある。それは，けっこうイケテル方法である。

わかってみれば，シンプルなことなんだけどなあ。

擬似コードというのが，あまり好きではない。コードみたいだけど，実際にはコードじゃなくて，そのままでは動かないもののことを擬似コードという。ちゃんとわかっている人の書く擬似コードはちゃんとしているのだけれど，ちゃんとわかっていない人の擬似コードはちゃんとしていないので，それは実装できなかったりするのだ。

プログラミング言語はかなり進歩しているので，擬似コードを書くよりも，動くコードを書く方が手っ取り早いことが多い。

UML（Unified Modeling Language）でさえ，私は疑問だったりするのだ。コードを可視化するツールとしては有効だけれども，UMLで仕様を書くというのはなあ…。生産性の高い言語でプロトタイプ作る方が早いんじゃないかなあ。

そう考えると，UML自体が，ウォーターフォール大規模プロジェクトを引きずっているのではないか？

反復型（iterative）アプローチは，個人的には納得している。ペアプログラミングは，うーん，やらないで済むならしたくないかな。一人で仕事したいタイプだし。管理職や経営者だったら，ペアプログラミングをさせるかもしれないけど。さぼらせない手法，品質を均一にする手法としては，有効な気がする。

プログラミングにも，哲学があるってことかな？

H2