データベースに接続してデータ取得更新するための部品(以降accessorと記)を作った。
あとは一定のフォーマットに従ってSQL文を設定すれば、
呼び元からは望みどおりの動きをする部品の土台まではできた。


んでもって、
それを使って今回新しいテーブル用のaccessorを作ってみた。
項目のタイトルを定義して、
英語に翻訳してテーブル項目名とし、
1レコード分のデータ格納場所としてのEntityを作り、
accessorの本体を作り、
1件Select、複数件Select用のメソッドを作り、
1件Insertのメソッドを作り、
1件Updateのメソッドを作り、
1件Deleteのメソッドを作り、
そしてコンパイルが通るところまで。


なんだろ。
とりあえず、今回は1時間半くらいかかった。


その昔JavaではMothodクラスを有効活用して実装していた機能では、
ツールを作っていて、
項目タイトルと、Javaソース用のオブジェクト名を定義し、
クラス名や変数名を定義すれば、そこから上記文と同じものができた。
これらにかかる時間は10分程度である。


作成までの操作もツールに固めておいたほうがすんげー楽で、
ほぼ間違いようのない手順で作成することが可能となっていた。


同一人物が同じことをした場合、
不完全なものが出来ている不安感のある1時間半と
99%出来てる安心感のある10分。


(´-`).。oO(ん〜。やっぱりこの差はでかいよな。)


そもそもの仕組みを作って、構造を知っている者が作業を行ってこれなのだから、
そうでない者が作業に従事した場合、1時間半で終わると期待出来はしないだろう。
最初は。
でもツールに固めれば1時間くらいで出来そうな気もする。
最初でも。

適用範囲模索

この1時間20分程度の時間差をどこに有効活用できそうかというと、
「仕組みの理解」にかける学習時間だ。
プログラムをえっちらおっちら作ることに悩む1時間と、
出来上がったソースを理解することに費やす1時間と、
どちらがシステムにおける学習効果が高いだろうか。
おいらは後者だと思う。*1


仕組みが単純であればあるほど、
この学習にかける回数も時間も短くなる。
30の手順を覚えるよりも、
3つの手順を覚えるほうが楽なはずである。
30の手順を実行するよりも、
3つの手順を実行するほうがミスは少なくなるはずである。


この最初必要になる学習時間の捻出。
そういえば作業スケジュールに的確に反映されているような
プロジェクトにはお目にかかったことがない。
学習時間の必要性は知ってはいても「やりながら慣れろ」ってのがほとんどだったなそういや。(゜Д゜)!


技術者のレベルと必要学習時間の相関が取れれば
的確なスケジューリングができるようになるのかな。
的確なスケジューリングがもたらす恩恵はデスマーチへの道を閉ざしてくれることにある。
根性じゃ乗り越えれない技術の壁を無視したスケジュールは不幸なのだ。
時間と経験が技術の壁を乗り越える力をくれる。


っと頭じゃわかっていても世間に示せねぇ・゜・(ノД`)・゜・
目の前の数値しか信じず、
本業にもかかわらず教科書知識程度しか持ち合わせない金持ちどもに
真理を知らしめる力量はまだおいらには無いことを痛切に実感。


とりあえず、仮説と実証を自分で行えども。
これって「おいら個人の経験談」にしかならんのだよな。
これでは世の中のシステム作りをことごとく失敗に導く7割くらいの人々に届くことは無い。
ココ参照
ヽ(´ー`)ノ

*1:プログラムの学習ということだと前者というけどね。