古き悪しき詳細設計書
詳しすぎる詳細設計書 - SiroKuro Page の続きです。前の記事ではブクマありがとうございました。
はてな界隈の拒否反応を見る限り、詳しすぎる詳細設計書に良い印象を持ってる人は少なそうです。もっとも、私は良い面も持っていると思っていまして、
- プログラマの技術的知識や業務的知識の量に左右されることなく、一定の品質を保つことができる
なんてメリットがあります。属人性の排除ですね。
あたりまえですね。実は設計者が書いたプログラムを詳細設計書と呼んでいるんですから。しかもテストどころか処理系に食わせてすらいないプログラムです。悪く言えば机上の空論です。良く言えば……絵に描いた餅？
プログラマの技能に左右されないかわりに設計書の品質に左右されるので、一定の品質が「悪い方に一定」だったりすることもあって、色々と下流工程の鬱憤が溜まりそうです。既に溜まっていますね、ごめんなさい。
本題：古き悪しき詳細設計書
いろんな人の反応にある通り『処理概要は不要。入出力定義だけガッチリ決めてもらえばプログラムは作れる』というのは、私としても同感です。*1
ただし、不要だからといって無視したところで、やはり邪魔になってしまう設計書も多いのです。簡単に言いましょう。
- 詳しい詳細設計書にはGOTO文やグローバル変数が書かれていることがある
前世紀に否定されたはずのスパゲティコードが、まだしぶとく残っていたりするのが詳細設計書というドキュメントだったりするのです。大域脱出を用いたロジックを java で実装するのは苦痛です。グローバル変数が使われていると見通しが悪いです。時折、java での実装が困難なロジックとかがあったりして、非常に困ることもあったりします。
詳細なロジックを全く書かないというのもどうかと思うのですが、せめて２１世紀らしいロジックを書いてもらえれば、と切実に思っていたりします。詳細設計段階では、まだまだフローチャートが現役なのです。
- 匿名関数を理解しようとしてフローチャートを書き始めるのは、大きな間違いです。
- SIer は、EXCEL 方眼紙の上にプログラムを記述します。そのプログラムは詳細設計書と名付けられ、テストされることなく出荷されます。
- SIer では、プログラムはドキュメントです。丁寧に印刷されてバインダーに綴じて、そして神棚に飾って手を合わせます。
- まあ仕事するぶんには良い職場だと思ってますけどね。自分が必要とされるなら尽力したいですし、自分がどれだけのことをできるのか考えただけでもわくわくしますし。
- この業界を変えていくのが万一億一自分だったりしたら、それはとても嬉しいことだな、と思っていたり。
閑話休題。ひとまず詳細設計書には意味を与えるべきです。機械的実行が可能な表記法を定義し、それに則って記述するべきです。なんなら「詳細設計書を読み込んで実行するプログラム」があれば良いでしょう。*2
意味を与えられず曖昧なまま記述されるプログラムは、得てしてバグの塊です。そしてそんな曖昧プログラムを、正当なプログラムに翻訳する作業は、やはりコツが要ります。最低でも翻訳先言語とパラダイムを揃えて欲しい、そういう意味でも『古き悪しき詳細設計書』は何とかしなければ、と思っています。
最後に１つだけ。
tnakamura システム開発 SQLで書けばもっとシンプル。 メモリ上のデータもＳＱＬで処理したい。 2010/01/07
http://b.hatena.ne.jp/tnakamura/20100107#bookmark-18389018
あ、SQL なら詳細設計書に直書きされているので、それを使えば大丈夫ですよ。たぶん誰もテストしたことのない SQL ですが。
