« 認知的不協和論文の確率計算 | トップページ | Quality は従属変数 »

2008年4月15日 (火)

プログラム設計書を書く目的

例えば、誰が書いても同じコードにするために、プログラム設計書(内部設計書)を今、書かせているとしたら、そんな無駄なものはやめたほうがいいと思う。

浜口さんに贈るSI業界を良くする方法 (ひがやすを blog)

プログラム設計書を書く目的というのは、”仕様の確実な伝達”ではないですかね。"誰が書いても同じコードにするため”ではないように思います。結果として、誰が書いても同じコードにはなるでしょうけど。設計書にある擬似コードをそのままコーディングすれば、同じになりますからね。

設計書の擬似コードと異なるプログラム・コードを書いても、別にかまわないはずです。

ただし、

設計書の擬似コード ≡ プログラム・コード

であることを、プログラマ自身が証明しなければなりません。表現の異なる2つのプログラムが、equivalent であることが、常に証明できるものなのかどうか、私は知りませんけど。

結局のところ、プログラムの仕様とは何で、それを伝えるためには、どうすればよいのか、というのが問題なんですよね。抽象的な文言というのは、その背後にあるコンテキストを共有していなければ、”正しく”解釈ができないわけでして。コンテキストを抜きにして、仕様を伝えようとすれば、結局、仕様とコードは表現が限りなく近くなってしまう、というジレンマがあります。プログラム・コードというのは、コンテキストのない表現の見本みたいなものですから。

プログラマに、システム化対象の専門領域について、コンテキストを共有してもらう、というのは、確かにひとつの手段なのですが。私には、プログラマがそれを望んでいるか、確信がもてなかったりします。プログラマは、プログラミングのために、”必要最低限の情報”を求めているようにも思えます。それが擬似コードであるというところが、なんだか、皮肉な感じではあるのですけどね。

|

« 認知的不協和論文の確率計算 | トップページ | Quality は従属変数 »

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



トラックバック

この記事のトラックバックURL:
http://app.f.cocolog-nifty.com/t/trackback/80472/20237766

この記事へのトラックバック一覧です: プログラム設計書を書く目的:

« 認知的不協和論文の確率計算 | トップページ | Quality は従属変数 »