不可能へのチャレンジ

最近の仕事ではこれでもかーーってくらいにレビューがある。
紙を作る基本〜詳細設計ってフェーズから
ソースコード作る工程も。

もーあれじゃね？
クラス図とシーケンス図まで作ってなお、ソースのウォークスルーとか無駄じゃね？

なんだか心配で心配で心配でしかたがなくて、
心配していないほうがよかったと後からしみじみ思うようなことをしていると思う。
いや、している。

ちなみに、いろんないわゆる設計書をつくり、
ソースも作らないうちからクラス図をつくり、
「これでリスク回避だ」っと思い込むために苦労を背負い、
あとは製造工程だ！なーんて言っているけれども
設計図の通りに作ってテストすれば考えることなく出来るー
っと思惑通りになんて行っていない。
製造ではなく製作している。
OOPとしてあるべき姿を模索すべく単機能にまとめるためにクラス作るとか
インタフェースを定義しなおすとか、アダプタクラス用意して出力状況限定するとか
非常ーにしづらい。
クラス数を限定し、メソッド数を固定化することはリスク以外の何者でも無い。
がんばって紙切れつくったら、その通りに作ってみたくなるのは願望として理解できるがの。

やはりあれだな。
ドキュメントとプログラムコードは
１．ドキュメント、２．プログラムの順で作成せずに、
１．ラフスケッチ、２．プログラム＆ドキュメント
くらいに並列で作るほうが、いろいろ手戻りがなさそうだ。

・どっちも設計思想は変わらない
・同じ事いうにしても英語と日本語じゃ表現方法が違う
・ソースとドキュメントももちろん同様
・ドキュメントを作るときの根拠は「過去の事例、過去の経験」
・ソース作って試せば済むことも「試さず考える」ってことをしてる
・試さず考える時間が無ければアリな気もする
・最初から全てを見切れる人がどれほどいるというのだ？
・いやいない。
・神のような人材を前提とした工法は一般的ではない
・っというか不可能である

紙は紙。プログラムはプログラムで割り切って作りあげるために、
英知を生かすほうがやりがいもよりよい結果も出るのだが
日本の大きな組織では効率よりも大いなる無駄を好むようだ