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