■
(1)かるく実装設計をやる
(2)とりあえず動くものをつくる
(3)きれいに仕上げる
ってなことをやっているだろうか？
(3)がすっぱり抜けていたりするんじゃなかろうか。
新人ってかビギナーレベルさんは(2)で満足される傾向がある。
( ´∀｀)＜動いたー。ばんざーい。
一皮剥けないミドルレベルさんも(2)で満足される傾向がある。
( ｀Д´)＜動いた。もーこれでえーやん。
プログラム作成にかかるトータルコストを削減することを念頭においている者達は違う。
( ´∀｀)＜さて。どう書けば美しいソースになるだろか。
もちっと細分化するとこうなる。
(1)かるく実装設計をやる
(2)とりあえず動くものをつくる
(3)実装形態をもとに再設計する
(4)リファクタリング、もしくは再実装を行う。
(5)動作とソースの確認
「きれいに仕上げる」ってのが(3)〜(5)に分かれた形だ。
一般的な言葉でこんなのがよく聞かれる。
(;´Д｀)＜そんなん時間かかるだけやん
だれしも出来上がったとおもわしきものを大事に仕舞いたいもんである。
「出来上がった」という一見の事実にすがるものである。
そんなやつらに一つ聞くのである
(,,゜Д゜)＜そーやって作ったプログラムが火を噴く原因であることは知っているのか？
いつも帰ってくる言葉は2種類。
(;´Д｀)＜そんなこと言われてもスケジュールは詰まっているんだし・・・
ってのか、
( ｀Д´)＜おれのは大丈夫。
である。
品質がおぼつかないものを完成品として扱えてしまう現代のシステム開発の仕組みはどうかと思うのだが、
これはまだ現実である。
ウォーターフォールは依然として生き続けているのである。
悪しき習慣はしぶといのある。
嘘をつきつづければ、「システムテスト」までは誤魔化せたるする。
おれのは大丈夫なんて言ってたやつのうち何人かはそんなことしてた。
ってか結果的にバレてた。当然である。
ざまーみさらせと思わなくもないが、
そんなやつの穴を埋めるのは結局、同じプロジェクトの自分達なのである。
厄介事は舞い込んでくるのだ。
なので。
開発中から調整を始めなきゃ遅いことに気づく。
そいつらが見かけ上のスケジュールに奔走している間に、
コーディングされたものの品質を確認するのである。
(,,゜Д゜)＜ダメはものはダメ
こう言えないことには死の行進に引きずられてしまうのである。
こんなことがうまいこと繰返されていると。
プロジェクトは案外うまくいく。
見やすく分担のはっきりしたクラス構成、ソース構成は、変更修正に対して強い。
修正範囲も影響範囲も予測しやすい形なのである。そう作るのだ。
会社ぐるみのサポート体制ができるようなデスマーチとは違い、
平穏無事に終わるこんなプロジェクトはいまいち宣伝効果は低い。
プロジェクトにかかわらなければ、何があったかすら知る必要すらない状態なんだからしかたがない。
ちょっと寂しいものがないこともないヽ(´ー`)ノ
ついでに残業大好きな根性論しかもってないマネージャ受けは悪いが、
そんなやつに受けてもしかたがない。
効率と成果好きなマネージャと仲良くなれるほうが1000倍ましである。
ちなみにこんなことは(1)についても言える。
日本語満載の仕様書を元にして、ダイレクトにプログラムを作る。*1
こんなことがビギナーにできるのか？
いやできまい。
しかしてそれをやろうとするからいつまでも動かないプログラムと格闘するとこになるのだ。
格闘時間が長いからとりあえず動いたときの達成感は大きく、
大きいがゆえにそれ以上やらないってな心理状態に陥る。
これは成りたてなミドルレベルもいっしょ。
運用保守状況を踏まえずに製作作業を行うものはほぼ同じようなことを言う。
最後に。
上記で細分化した(1)〜(5)だが、
効率を求めた上ではもちこっと変わる。
(1)かるく実装設計をやる
(2)(1)を元に今の自分にわからない部品群をまとめる
(3)とりあえず動く部品を作って動作を試す
(4) (2)〜(3)をもとに再設計する
(5)(1)を元に製作を始める
(6)必要に応じて再設計
(7)動作とソースの確認
ユニット単位で物作って、テストして、そいつらを使ってプログラムを仕上げると。
早い話がこんなこと。
手順もプログラムもよりよく更新し続けることは大事なのである。
