「ほれみたことか」な話

以前に色々愚痴った話ですけどね、まぁ記憶にないんですけどね。

設計書ってこんなんじゃないよねと言ってたような言ってなかったような。

まぁとにかく悲惨な設計書についてコンサル会社からズタボロに言われてて「あーあ」となったんですよ。

コンサル会社側はあるべき論を謳ってましたけどね。詳細までみるとツッコミどころ満載でしたけどね。

正直なところズタボロに言われた方もズタボロに言ってきた方もどっちも情けない。
協力会社の立場でしたからね、何も言わなかったですけどね。
受託してる側からしたら「ほれみたことか」だし、公開処刑してきた方の言い分も「いやおかしくね?www」だし。
まぁそんな打合せに巻き込まれたんですけどね。
人集めていうことでもないよなーと。
まぁ僕は別の案件に突っ込まれるので被害は小さいですが。

とりあえず何言いたいかよくわかんないけど「真面目に仕事しろや」ということですまる。

POIを使用せずにxlsxをjavaで読み込む

POI便利っすよねー。

Excelデータの操作をJavaで行うなら必需品です。

だがしかーし!使えない時もある!

POIが悪いんじゃない。使うなという企業が悪い。
開発環境に"自由"にライブラリを設置できない場合、ネイティブでやるっきゃない。

"自由"とは責任をもってやること

ターゲットをxlsx形式のみにしたら比較的容易にできる。
Office Open XMLなのでDOM解析すれば良い。

続きを読む

条件網羅できてない設計に対する実装

もうね、アホかと。

別チームが決めた条件分岐に対して if() if() if()... と分けて実装しようとしている。

データは単一の条件にのみ該当するのが理想。
しかしこの条件分岐には欠陥がある。
複数の条件に合致したり、どの条件にも該当しない。そこまで判明してて実装方法は変えない。

実装を変えないのであれば重複と欠落、本来該当すべき条件にならないデータの存在を許容するか、相互に排他的な条件となるように見直しを仰ぐべき。

どの手段もとらず、全データを処理すべきならば if () elseif () else とするのが安全。結果はヒットした順で処理されるため優先度の策定は不可避だが、なによりも重複と欠落は発生しない。存在しないデータよりも存在するデータからの原因究明の方が低コスト。この手法の方がアドバンテージあるようにみえる。

なのに今の現場では if() if() の実装を避けず、重複は個別に排除し、欠落データのハンドリングも行わない。仕様の見直しも行わない。

保守フェイズでの炎上っぷりは、字面の通り火を見るよりも明らか。

さっさと離脱したいなー。