システム開発■ 途中経過
随分と前に、電子記録債権を支払系でも使えるようにする修正を始めたと書いていましたが、かなり難航しています。
理由は色々あるのですが、外的な要素として会社自体に色々と問題が発生して、電子記録債権よりも優先度の高いシステム改修の依頼が出て来たことです。要は統制機能の強化で、特定の処理を権限のある人しかできなくする類の修正です。
システム云々って話だけでなく、業務処理自体にかなりメスが入っていて、そっちの対応が優先していたんです。まぁ、修正内容を聞いた時点で、会社に何があったのか分かりそうなものですけどね（苦笑）
もう一つは、私の問題。前回の開発（基幹システムの電子記録債権への対応 Part1 始まり）と違って、細かい設計をしないままに実作業（プログラミング）に入ったので、手戻りが多いんです。大きなレベルでの構想は考えていたのですが、細かい機能単位での連携は作りながら考えるという雑な方法を取ったことが間違いの元でした。
と言っても、設計も開発も私一人なので細かく考えることに時間を使うよりも、手戻りを覚悟して開発した方が結局は早いだろうという想定なので、これは予定通りですかね。
そして、もうひとつ問題が・・・
■ 問題
勤め先のシステムは、既存のERPパッケージを使わずに、一からスクラッチ開発したものです。そのため、それなりの人数が開発に参加していたのですが、人数が多いという事は、開発者のレベルにもバラつきがあるわけでして・・・、要するに主力は受発注とかに割かれていて、今回の開発対象である支払系に投入されたプログラマは一つレベルが落ちるようなのです。
例えば、これ。
// 相殺処理
int creatPymFlag = this.updateCompanyPaymentInfometion(pymList);
// --------------
// 処理分岐
// --------------
// 現金のみ
if (creatPymFlag == 1) {
・・・
}
// 手形のみ
if (creatPymFlag == 2) {
・・・
}
// 現金と手形の両方
if (creatPymFlag == 3) {
・・・
}
}
嫌らしいのが、最初の相殺処理とやらで動かしている「updateCompanyPaymentInfometion」です。中身は、とあるテーブルの更新なのですが、同時に対象となる支払金種の判定をして、以降の処理判定で必要なフラグを作成して返却しています。
これ、一つのメソッドに複数の機能を実装する神経が理解できない。しかも、フラグが何故かint型（別にint型でもいいのだが、個人的に気に入らない）。そして、処理を抜けた後のif文の最後に「現金と手形の両方」とかいう洒落にならん判定条件を付けている。
このプログラマ、金種が増えることを考えていないようですね。確かに、金種が増えるなんて滅多にないかも知れませんが、それにしてもこれはちょっと・・・
まさか、現金と電子記録債権、手形と電子記録債権、現金と手形と電子記録債権、・・・なんてパターンを作るわけにも行かないしなぁ。
■ 後書き
突っ込みどころは、他にも満載しています。引数としてマップを受取っているメソッドがあるのですが、何を思ったのかメソッドの先頭でマップに格納されたデータを全て取り出して、個別の変数に書き出したりしています。
しかも、処理の中でも大量に変数を生成してるし。結果、プログラムはスパゲッティ化。当然、肝心な個所に限ってコメントは無いし、書いてあっても実装と異なっているし、もう、何というか、０から作り直したい（泣）。
別に、私のプログラミングレベルが高いとは思いませんが、何というか、最低限守るべきものがあるのではないでしょうか。
前回：基幹システムの電子記録債権への対応 Part12 支払系の解析
次回：基幹システムの電子記録債権への対応 Part14 譲渡の実装
投稿記事の一覧：http://harikofu.web.fc2.com/
--- blog end ---
スポンサードリンク
0
0
