  |
今作ってる典型的なJavaのMVCモデルのWebシステムでの話。
結論から言うと、プログラムやクエリを和訳したレベルまで細かく書くのは無駄だと思ってる。
特に一番嫌いなのが、クエリを和訳した文をそのまま詳細設計書内に書けって言ってくるレビュアー。今のチームのレビュアー様である。
テーブルと列、検索条件、ソート順、結合あるなら結合条件も書けと言ってくる。
まあ単純な主キー検索等しかないシステムなら別にいい。書くよ。
だがそんな単純なクエリだけでそこらのシステムが成り立ってるならこんなこと言わない。
大体今日びORMも導入せず処理の途中にクエリをベタ書きするような糞システムもそうそう無い（とはいいつつ去年見た）っていうのに。
クエリを和訳したような設計書を書くくらいなら、いっそ設計書からクエリを自動生成できるようにすればいいじゃないかっていうことで、余所の部署で作られたマクロ付きの設計書を拝借してきて今回DB関連は全部そっちで定義してある。
にも関わらず、「ここにもさらっと書いておいてよ」とレビュアー様はのたまう。いやいやさらっと書けないから別のドキュメントにしてるんですが。
んでレビュアー様のご指摘どおりに直していくと、結局別出しにしていたクエリ設計書と全く同じことを詳細設計書にも書くハメになる。
そこそこ大きなプロジェクトで、基本設計、詳細設計、さらにプログラム設計書を作ることになったのだが、このレビュアー様がレビューしまくってして書き直させまくった結果、詳細設計書とプログラム設計書はフォーマットが異なるだけで記載内容がほぼ一緒になってしまったのだ。
当時設計書の修正だけでかなりの工数を使った結果上からも下からも総ツッコミを喰らってかなり痛い目見てるはずなのに、また同じことを繰り返しているから救いようが無い。
プログラムが書けない典型的な文系SE様に今更Javaでプログラム書ける様になれとは言わない。
ただ詳細設計のレビュアーを任されるような立場ならば、せめてそのシステムで使われてる言語やフレームワークの特性ぐらいは把握しておくべきだ。
それも嫌ならせめてフロー図くらい読めるようになってほしい。フロー図作れって言っておいていざ作ったら「このひし形って何？」って聞かないでお願いします。
32
