■なぜソースじゃなく詳細設計を欲しがるのか

Javaを始めとするオブジェクト指向言語による開発になると、設計の手法も従来とは大きく変わる。

その結果、不要になるドキュメントが出てくる。

詳細設計のことだ。

ここでいう詳細設計とは、本来コードで記述する処理を、逐一日本語で書き下したものを指す。

てか、そんな物を読むくらいなら、現物のソース読めよって話だ。

だいたい、ソースに書くレベルの粒度の記述を、なんでいちいち日本語なんて表記揺れも甚だしいフォーマットで書かにゃならんのだ。

何よりソースに修正が入ると、遡って詳細設計も直さないと整合性が取れなくなるので、言うなれば二重に工数を掛けることになる。

「違うよ、設計を直して実装するんだよ」というが、合理性を重んじるSEやPGという人種が、実質同じ内容を何度も書きたがるわけがない。

それに、単体テストくらいまでの段階ならともかく、開発要員が縮小される結合テスト・システムテスト以降で、そんなことをしている余裕など現場にはない。

結果、実装と合ってないドキュメントだけが放置されてしまう。

でも、そうなることが目に見えているにも関わらず、欲しがる客や元請が後を絶たない。

負担ばっかり増えて、尚且つ無意味な作業をやらせるなって感じ。

なんでそんなに「日本語訳」が欲しいの？

ぶっちゃけソースコードレビューでいいじゃん。

もし客がソースを読めないなら、その時に客が読みたい部分だけを元請が訳して説明すればいい(全部読みたがるヒマな客なんてそうそういないだろうし)。

そして元請はITのプロなんだから、ソースなんてスラスラ読めて当然なわけで。英語読めない英語の専門家が存在しないのと同じ理屈ね。

それこそ読み取り専用でリポジトリのアカウントの一つや二つくらいいつでも作れるので、ソース抜き打ちレビューどうぞって話だ。

とはいえ、別に何も「真実はソースただ一つ！」なんて言うつもりはない。

ソースに行き着くまでにも考えることは色々あって、その考えた結果は全て形に残さなければならない。

ソースもまた考えた結果の成果物の一形態であり、他の形態が、各フェーズで書くドキュメントなのだと思っている。

そしてドキュメントがあるお陰で、システムがトラブった時もいきなりソースの問題箇所を探し回る苦労から解放されるのだ。

ドキュメントを手がかりに「このクラスの、このメソッドが怪しい」まで行き着いてから、そこで初めてソースを確認すればいいと。

Javaだったら、ユースケース図、アクティビティ図、クラス図、シーケンス図、Javadocによるメソッド説明と読み込んでいってアタリを付け、それから当該メソッドのソースを読めばいい。

逆に言えば、記述の粒度が同じ成果物は2種類以上も要らない。整合性を保つための手間が増えるだけなので。

詳細設計書は不要というのはそういうことだ。

つーか「ソースが読めないから日本語訳を渡せ」とか甘えんな。

Permalink | 記事への反応(5) | 15:53

ツイートシェア