Hatena::ブログ(Diary)

SiroKuro Page RSSフィード

2010-01-07

古き悪しき詳細設計書

詳しすぎる詳細設計書 - SiroKuro Page の続きです。前の記事ではブクマありがとうございました。

はてな界隈の拒否反応を見る限り、詳しすぎる詳細設計書に良い印象を持ってる人は少なそうです。もっとも、私は良い面も持っていると思っていまして、

なんてメリットがあります。属人性の排除ですね。

あたりまえですね。実は設計者が書いたプログラムを詳細設計書と呼んでいるんですから。しかもテストどころか処理系に食わせてすらいないプログラムです。悪く言えば机上の空論です。良く言えば……絵に描いた餅?

プログラマ技能に左右されないかわりに設計書の品質に左右されるので、一定の品質が「悪い方に一定」だったりすることもあって、色々と下流工程鬱憤が溜まりそうです。既に溜まっていますね、ごめんなさい。

本題:古き悪しき詳細設計

いろんな人の反応にある通り『処理概要は不要。入出力定義だけガッチリ決めてもらえばプログラムは作れる』というのは、私としても同感です。*1

ただし、不要だからといって無視したところで、やはり邪魔になってしまう設計書も多いのです。簡単に言いましょう。

前世紀に否定されたはずのスパゲティコードが、まだしぶとく残っていたりするのが詳細設計書というドキュメントだったりするのです。大域脱出を用いたロジックjava で実装するのは苦痛です。グローバル変数が使われていると見通しが悪いです。時折、java での実装が困難なロジックとかがあったりして、非常に困ることもあったりします。

詳細なロジックを全く書かないというのもどうかと思うのですが、せめて21世紀らしいロジックを書いてもらえれば、と切実に思っていたりします。詳細設計段階では、まだまだフローチャートが現役なのです。

閑話休題。ひとまず詳細設計書には意味を与えるべきです。機械的実行が可能な表記法定義し、それに則って記述するべきです。なんなら「詳細設計書を読み込んで実行するプログラム」があれば良いでしょう。*2

意味を与えられず曖昧なまま記述されるプログラムは、得てしてバグの塊です。そしてそんな曖昧プログラムを、正当なプログラム翻訳する作業は、やはりコツが要ります。最低でも翻訳言語パラダイムを揃えて欲しい、そういう意味でも『古き悪しき詳細設計書』は何とかしなければ、と思っています。



最後に1つだけ。

tnakamura システム開発  SQLで書けばもっとシンプル。 メモリ上のデータSQLで処理したい。 2010/01/07

http://b.hatena.ne.jp/tnakamura/20100107#bookmark-18389018

あ、SQL なら詳細設計書に直書きされているので、それを使えば大丈夫ですよ。たぶん誰もテストしたことのない SQL ですが。

*1:「まずは入出力を厳密に定義しなさい」とは、私の大学時代の恩師の言葉でした。その先生の専門はプログラム意味論です。とても良い先生だったと思っています。

*2:そういう観点でも、やっぱり escafeFlow みたいなものは面白いな、と思っていたりします。

はてなユーザーのみコメントできます。はてなへログインもしくは新規登録をおこなってください。

トラックバック - http://d.hatena.ne.jp/SiroKuro/20100107/1262871502