classファイル単位でリリースするという愚行

銀行系の案件は本当に辛い…
存在しているだけで苦痛な案件って、本当にあるのですね。

というわけで、
今回もSIerの毒吐きです。

具体名を出さなければ訴えられることもありませんし、
ガンガン突っ込んでおきましょう。

本日の話題は、
Javaのソフトウェアのリリースについてです。

銀行系でなくとも、
Javaならそれなりソフトウェアであれば、
それなりのclassファイルが生成されます。

ただ銀行系のおそろしい所は、
各classファイルの更新日時とサイズを控えておいて、
リリース時に１個１個確かめながらコピーしてリリースすることです。

彼らには、
jarファイルやwarファイルやearファイルにするという発想はありません。

いえ、存在は知っていても信用していません。

どうにも人力チェック＞自動チェックという根深い信仰が存在していて、
人間の眼を通さないと気がすまないのです。

classファイルとjavaのソースファイルの数は一致しないので、
それこそリリース漏れの原因だと思うのですが…

というよりも、
リリースってantなりMavenなりで手順を簡素化するものじゃないのですか？

自分の意見が採用された案件では、
全サーバーのリリースがバッチ1個実行するだけで終わりますよ…
(まあこれはTomcatの機能を使ったwarの自動デプロイですけどね。)

それにビルドサーバーがなくても、
ビルド用の端末を決めていたのも大きかったです。

リリース＋更新の確認にかかる時間は、
おそらく10分もかからないでしょう。


では今の案件でそれを提案しないのか？

自分はあがく者の味方です。

自己の錬磨を怠る者を、
助ける義理は持ちません。
(じゃあ自分で自分を助けないんだよなぁ…というのは置いておいて。)

classファイル単位のリリースに疑問すら抱かない者を、
自分はあがいているとは見なしません。

自分はそこから抜ける準備を進めるので、
勝手に炎上してくださいとしか言えません。


…ふう、本当に早く抜け出さないと。

銀行系の炎上は人災です。

1人じゃありません。

顧客とSIerがタッグを組んでキャンプファイヤーをしているのです。

やるのは自由でしょうけど、
周りの林や森に飛び火させるのはやめてほしいものです。

追記：
うわ！やっぱり弊害があった！
メソッドの引数変えたらオーバーライドで別メソッド扱いになるから、
そのメソッドを呼び出している箇所でNoSuchMethodが起こるじゃないですか！
関連箇所を洗い出してコンパイルし直さないといけないです。
なんでそんな縛りプレイをビジネスでするのでしょうか？