アプリケーションアーキテクチャ設計パターンを読み始めた

　
言うまいと、思えど財布の寒さかな (パクりましたぁっ！)

Xamarin と規模で対極にありそうな、JavaEE 関連の設計段階に焦点を当てた本。

暫く、完全な EE とご無沙汰なので、新刊ででたのを読むことにした。

ウォーターフォールの巨大システムに関わる気はさらさらないんだけど…

意外に、さらさらと読めている。ただし最初は、アバウトな説明だしね…

やっぱり、わたしは、
プログラミングもする(ＡＰＩ)、アプリケーションアーキテクチャのサポーター
あたりの立ち位置が合ってるなぁ。
(どこでも、外の人間だからね)

人手不足でかり出されると、
設計が終わったので、設計書と一字一句違えないプログラムを、
ガシガシ作れという、大っ嫌いな指示がきて、大概は設計書が不完全。

この仕様間違ってる、なんて言おうものなら、
後で仕様変更で別料金を請求するんだから、仕様通りつくれと。

だって、ロジックにミスがあったらテスト通るわけないじゃんね。

色んな所で「別料金」をいいきかされて、結果プログラマを不要な疲弊に追い込んでる。
始めから外のエンジニアは使い捨てだもんね。
「絶対、あそこには二度と行きたくない」と言われる会社や部署になれます。おめでとうございます。

だからぁ、部隊はアーキテクチャと業務で分けて、
業務がユーザと仕様をしっかりつめて、
アーキテクチャはその間にモジュールとかクラスの粒度の検討やら、
詳細設計やコーディングをいかに負担少なくやらせるか、
そこに知恵を絞る…(たまに、干からびたりする)

並行(並列・逐次には、全てが縛られる訳ではない)に、人材を投入できるのにね…

まあね、それじゃ初回は大幅な黒字(儲け)は見込めない。
確実に黒になるのは、アーキテクチャ部隊が上手に立ち回って、
早くても、類似の仕事の三回目以降っていうのが、経験値かな。

でもさ、毎回類似した仕事なのに、延々大きな赤字だし続けるよりは、
多分２年程度でまずは信頼を得られるし、早ければ黒字に転じる。

営業だって、飛び込みにはなるけど、飛び込み先を無鉄砲に決める愚は回避できるよね。
(何でもやります！なんて仕事探してくるんだよね

ま、理想を言って貰っては困るって事なんだろうけど、
赤字を出した同じ轍を踏み続けるよりは、いいと思うけどねえ…

　