設計書ってさ。

ある職場で、設計書書いてた時の話。
レビュー時の指摘事項で。
・処理の階層が深すぎるから、そうならない様にして。
・サブ処理として書かれると、判りづらいから、そうならない様にして。

で、思ったのが…
「…それ、相反してなくない？」

フラットに書いたら、深くならざるを得ないと思うし、自分としてはそうならない様に…と思って、サブ処理の記述にしたんだけど。

で、既に有る設計書見てみたらば、
・処理のブロックは罫線引いて区別する。
　（当然、ネストもそれで表現）
・結果として、「項番が深くならない」。
という事だったんだけど。

（深くしないのは、項番であって処理ではないって言うね (^_^;)）

ただ、詳細設計書として考えた時に、これをそのままコード化なんてしないから（したら、読み辛くってしょうがない）、サブ処理に分けるんだけど、そうなったら、設計書とコードの乖離が発生しないかな…と。

個人的には、もうこう言うドキュメント（設計書）は書かない方向で良いんじゃないかと思ってる。
勿論、「するべき事」を書いたドキュメントは必要では有るけれど、コードと１：１になる様に記述する設計書は無くてもいいと思う。
改修しても、コードだけ修正してドキュメントなんてメンテしないだろうし。

例えば、バグが出て改修しても、改修後のテストはしても、改修に先立ってドキュメント修正→レビュー→改修なんて手順踏んでるところって（自分が見た限り）無いと思う。（個人的にやってた事は有る）
ドキュメント大事。と言うなら、本来そう言う手順を踏むべきだとは思うんだけどね。

あと、ドキュメントのフォーマットもね。会社毎とか、ベンダ毎に違うのも……どうにかならんのかな。
あんなに「業界標準」が好きな業界なのに、こういう所を標準作らないってのもね。

結局、大手がメインフレームやってた頃のやり方をそのままSAPに持ってきてるから、そんな事になってるんよね。

むぅ。どーーにかならんもんかな。