ベンダーでＢＶを使って開発している方に質問です。

質問

ＶＢで開発を請け負っている人に質問です。（逆の立場の人でもかまいません）

開発にはノータッチで完成してからお前が運用を考えろと渡された、人事管理
システムがあります。この中に名簿の定型帳票があり１万ステップを超えて
いるので改修は許して欲しいと言うのプログラムがあります。

先日バグの切り分けの為にシステム設計書、概要設計書及びプログラム仕様書
を見て「バカやってんじゃねぇーよ！」と怒ってしまった。私はＶＢの知識は
ありませんが、要求されている仕様を整理すれば１～２千ステップもあれば
書ける内容を、概要設計から出力フォーマットに沿った説明をコーディング
レベルまで持ち込み大きなステップ数になっているのが判りました。
（推測ですが、以前はAccessで開発されていたものをセキュリティーやメンテ
　ナンスの理由から書き換えを行ったことからAccessのクエリー等をそのまま
　ＶＢに置き換えたのかも知れません。）

システム設計の先頭にメンテナンスビリティーを重視した開発を行う事と
あるのに、この帳票は部課コードを始めにコード類は殆どConstant Valueを
使っていて組織変更等がある都度変更の必要があると言う優れもの。

開発の当社側担当の無能さもさることながらＶＢで開発されている方はこんな
レベルが低いのかと呆れた次第です。汎用機を扱うベンダーであれば効率性や
メンテナンスの事を良く考え、詳細設計書に書かれている内容では、それらが
損なわれると判断すると、設計の変更を申し入れられる経験をして来た人間に
とって泥棒並のベンダーとの思いもします。

回答No.2

imogasi

プログラムを組んで、他人様からお金を貰ったことのないノンプロが言うことですから、適当に聞いてください。
Ｃｏｎｓｔの件は、（１）数学定数的なもの、Ｐａｉなど（２）システムコード的なものｘｌ・・・やｖｂ・・・など（３）ＭａｘやＭｉｎなど限界値（３）世俗的なコード、人事部を３と決めたなど（５）世俗的定数、消費税率など考えられるが（３）（４）（５）は変更がありえるので、プログラムの一箇所にまとめておいて、そこを変えれば済むようにするのは、常道ではないでしょうか。
もっと印刷の設定のエクセルの画面や会計ソフトのように一覧画面にでもすれば判りやすいですね。手間はかかります。
また注釈は製作者ｘ社Ａ氏から将来改変するｙ社Ｂ氏へのメッセージ
とおもえばそれでいいが、全コーディング行に注釈行を入れると
２倍の量になり、今も料金はステップ数合計で、１ステップ単価＊行数で計算するのでしょうか。何となく水増し的でやり切れませんね。
ただ大型コンピュターメーカーのソフトが、立派だとは経験から思いません。（１）仕事を知らない。仕事のパターンを知らない。
（２）人間心理を勘案していない。（３）入力の大変さや大切さを良く
判っていない。（４）一部の欠点の為に全部が使われなくなることがあることを戒心していない。（５）総なめ法を取っていて、データ量が増えて応答や処理時間が極端に長くなる。などの欠点は良く体験しました。
しかし考えても見てください。約１０年前の大型コンピュターは、ウィンドウＧＵＩは本格的でなく、ＩＢＭのＧＤＤＭだったかは縁が遠くて終に使わずでした。それに比べＶＢで出きるＷｉｎｄｏｗｓのＧＵＩは多彩
です。Ｃｏｎｔｏｒｏｌ類を見てもこんなことも出きるのと、感心します。大きな可能性を見せてくれています。
ＳＥといってもコーディング規則を憶えてすぐ客先のシステムを組めと放り出されるひとも多いのではないですか。
結局発注先を規模人員数ネームバリュで選ばず、見極めるより手はないのでしょう。

お礼

ご教授ありがとうございます。ノンプロで良かったですね！

>>ＳＥといってもコーディング規則を憶えてすぐ客先のシステムを組めと放り出されるひとも多いのではないですか。

そう言う人は、駆け出しのプログラマーとしか見ませんから、ＳＥ給料の半額以下は当然で、
場合によっては、お荷物ですから研修の一環として無給でなら置いていいと言うスタンスを
取るのが多いのでは？

回答No.1

ARC

質問でしょうか、それとも愚痴でしょうか？
ＶＢでの開発に携わるものとして、十把一絡にして「レベルが低い」と決め付けられるのは少々心外であります。

CONSTについては、ある程度は仕方がない面もあります。
「部課Ａのときは処理1を行う、それ以外は処理２を行う」
ってなコーディングを要求されれば、どうしてもCONSTを使わざるを得ないですから…

(外部ファイルで部課ごとにフラグを指定して、それによって動的に処理を切り替える、って手もありますが、それにしても最低限、部課コード位はCONSTで定義しなくてはいけません。ステップ数も増えるでしょうし… なんでもかんでも外部ファイルで定義すればいいって訳でもないんです。）

ってことで、ＰＧの技量不足もさることながら、仕様を整理する側のＳＥの方により大きな責任があると思うのですが…

それはともかく、「とにかく融通が利かない」というイメージの汎用系ベンダに対して、ＶＢメインのベンダは、「とにかくお客様の要望を重視し、お客様の言ったとおりにソフトを作ってしまう」という傾向がありますね。

小回りの効く言語であるが故に、ある程度の要望にはその場で答えることができる為、言われたことを言われたとおりにホイホイ作ってしまう、っていうのはあるかと思います。

そういった傾向もあって、仕様書からの展開を馬鹿正直に行ってしまい、工数が馬鹿みたいに増えてしまうっていうことも、中にはあります。
(ですが、仕様書に素直なコーディングって言うのも大事です。その辺のさじ加減がＰＧの腕の見せどころかと思うんですが…)

※個人的な意見としては「１万ステップを超えているので改修は許して欲しい」などというプログラムは即刻破棄すべきだと思います(^^;。
この手の言い訳が付くモジュールは、大概、それを作成した人間しかメンテ出来ない(汗

お礼

嫌みな質問に誠実に答えて頂きありがとうございました。

>>質問でしょうか、それとも愚痴でしょうか？
　両方でしょうね！

>>ＶＢでの開発に携わるものとして、十把一絡にして「レベルが低い」と決め付けられるのは少々心外であります。
感情に流されて書いた事を反省しています。別案件C/Sの世界で、私がシス
テム設計した案件を担当してくれた人は適切なアドバイスをしてくれました。
そう言う人もいる事を忘れて言い過ぎでした。

>>この手の言い訳が付くモジュールは、大概、それを作成した人間しかメンテ出来ない
引き渡しを受けて幾つかのバグがあり、バグ取りと合わせて改修を依頼したら
書いた本人が判らないらしいんです。当たった人間が悪いと言うことなんでしょネ！

>>それはともかく、「とにかく融通が利かない」というイメージの汎用系
>>ベンダに対して、ＶＢメインのベンダは、「とにかくお客様の要望を重視し、
>>お客様の言ったとおりにソフトを作ってしまう」という傾向がありますね。

傾向が良く判りました。
プログラマーはそのレベルでいいでしょうが、ＳＥでと名乗る人間で、この程度の
人間に当たったら即刻首だなぁ・・・