Entry

ソースコードに書かれていないバグに関する情報の話

2011年03月20日

某氏……に限らず,巷でドキュメンテーションを嫌がっている向きが典型的に口にすることに,次のような話があります。

ソースを読めばなんでも分かる。バグもすべて書いてある。

以前もこの話を書いたかもしれないけれど,この命題は非常にトリッキーで詭弁的だと思っています。確かにソースコードにはバグも含めてすべてが書かれている。これは間違いありません。

しかし,ソースコードにバグが書かれていることが分かっていたとして,これは開発で必要な情報となりうるのでしょうか。あたしには,意味のない情報としか思えません。というのも,開発に必要なバグに関する情報は,「バグが書かれているか」ではなく「何がバグでソースコード上どう実装されているか」に尽きるからです。

そもそも,プログラムはプログラムした通りにしか動かないのだから,プログラム(ソースコード)の内部に「バグ」という概念はありません。通常,バグは開発者/設計者/ユーザが意図した通りにプログラムが動かないこと言います。

したがって,極端な話,他のプロセス空間を汚染してそのプロセスを暴走させるプログラム(ウィルスだが)を書いたって,「これは他のプロセスを暴走させるプログラムです」と言ってしまえば,バグのない正常なプログラムになる。そのプログラムがバグか否かは,プログラム内部で記述できるものではなく,プログラム外部の評価が必ず必要になるわけです。

よって,上の命題が実際に意味するところを書き下すと,次のようになるはずです。

ソースにはそのプログラムの動作がすべて記述されている。プログラム外部から見てバグと呼ばれるものもすべて書いてある。

この命題なら,より正確に真だと言えます。さて,問題はこの命題から次の命題を導出できるか,ということです。

したがって,(プログラムの外部的な評価である)仕様書/設計書は書く必要はない。

どうなんでしょ。あたしには,かなり限定された場面でしか,これが正しいとは主張できないと思います。どういう場面か。

  • そのプログラムに関わるすべてのプログラマ/開発者/ユーザが,正常系/異常系の動作を知っている場合。

例えば,OS 例外(access violation とか)で落ちることがバグであることは,大抵のプログラマ/開発者/ユーザで共有されています。メモリがリークする場合も通常はバグとして共有されている。あくまでも強調しておくけれども,これはそれぞれで共有されている認識だからこそバグと呼べるわけで,プログラムそれ自体がバグなるものを含んでいるわけではありません。つまり,「落ちる仕様のプログラムです」とか「リークするプログラムを書いたんです」と言ってしまったら,それはバグでなくなくなるとゆこと。バグなる概念は,常にプログラムの外部にあります。

で,そうしたはっきりしたバグは,通常の開発の場面ではあまり問題にならないんですね。問題になるのは,仕様なのかバグなのかがよく分からないところです。例えば,

  • MS Word のファイルを読み込む処理で,Word 97 のファイルを読むと正常に読み取れない。
  • CAD 図面のファイルを Postscript に変換すると,線の太さが一部異なる。
  • ある物理計算を行うソフトで,特定の処理を行うと精度が2桁落ちる。
  • スレッドの同期に意味不明の sleep が入っている。

のようなもの。こゆのは,プログラム外で文書化しておかないと,バグなのか仕様なのか絶対に分からない。なぜなら,その現象が意図/許容されているか否かの判断が共有されていないからです。

もちろん,「これは仕様/バグですか?」という問い合わせをすれば分かるわけだけれども,そんな手間をかけるなら文書化した方がいいし,そゆ質問に答えられる文書が仕様書であり設計書のはずです。変な開発者は,「プログラマは無駄な作業が嫌いだから文書なんか書かないんだ」とか言ってるけれども(カッコつけてるつもりなんだろうか),口頭の問い合わせに属人的に対応する方がよっぽど無駄だったりします。単に日本語書けねーだけだろ,と。

プログラマにどうしてこういう変な定言があるのだろう,と,いまだに疑問だったりする。どうしてかについては思うところがあるので,後のエントリに譲ることにします。

Trackback
Trackback URL:
Ads
About
Search This Site
Ads
Categories
Recent Entries
Log Archive
Syndicate This Site
Info.
クリエイティブ・コモンズ・ライセンス
Movable Type 3.36
Valid XHTML 1.1!
Valid CSS!
ブログタイムズ

© 2003-2012 AIAN