処理形態の話
プログラムビギナーにありがちというかビギナーはこれしかやらない処理形態がある。
「画面の入力値をそのままＤＢに入れる」*1
もーいまや考えるだにめんどくさい処理である。
いまや処理形態をわかりやすく保つためにも
安全確実な登録更新作業を行うためにも
堅実なチェックを行うためにも
「画面」→「ＤＢ」
ではなく、
「画面」→「一時的データ格納庫*2」→「ＤＢ」
っとしている。コーディング分量は増えるが画面やＤＢの仕様変化に強い。緩衝材万歳。
しかし、先の単純な「画面→ＤＢ」って実装形態にもメリットはある。
(1)の場合にはこれがすっきりするのだ。
項目数が少ない場合とかチェック内容が簡単な場合には〜という限定付で。
人の欲望とは果てないものだ。
最初は( ´∀｀)ノ＜こんな単純なチェックでいいよ〜
といわれたものも、
( ´∀｀)ノ＜これも追加して〜
( ´∀｀)ノ＜これがあるならあれもお願い〜
( ´∀｀)ノ＜あれまでついたらこんなのも無きゃね〜
( ´∀｀)ノ＜こんなのまでできたらいっそ（ry
多かれ少なかれこんな感じになる。なっていく。
お客さんの要望をどこで止めるかは渉外担当役の責務なのだが、全部止めれるやつなんざ皆無だ。
いずれ早晩やってくる。仕様変更はやってくる。開発中にもやってくる。
ってことが予想できる。ってか仕事経験をつんだ現代を生きるプログラマなら
そこに迫ってきていることを実感できる。リアルタイムで進行中かもしれない。
っということは。
っということはだ。
(1)のみに対応した処理形態では破綻しないことのほうが珍しいということになる。
「画面」→「ＤＢ」の処理形態はは作りやすいかもしれないが、危険と隣り合わせなのだ。
「早く実装したい」っていうのはわからんでもないから、
「早く実装しただけ」のソースを保守メンテするイライラ感を味わい、自己内反省を速やかに行ってもらうためにも、
若さゆえの過ちは冒して欲しくもある。
(2)の対応プログラムってのは技術的に難しいことは何も無い。
・その1「入力値を取得する」
・その2「いろいろチェック」
・その3「いろいろデータ整形」
・その4「DB登録」
この手順が大枠だ。大枠を外れなければ論理的に破綻することはない。
リファクタリングも大枠を外れなければラクチンだ。(1)よりははるかに。
そういう実感もあるので、今のところそんなのを踏襲している。
ゆえに。
踏襲していないソースをみたときには(´A｀)ウンザリしてしまう。
注意して直させようとしても。
今のところ「プロジェクトの見た目のスケジュール進行」の壁の前に敗れ続けているおいらがある。
うがー。
