他人が作ったプログラムのメンテナンス方法

質問

他人が作った、VisualBasicで開発されたスタンドアロンの会員管理アプリケーションソフトを、メンテナンス＆カスタマイズすることになりました。
良くあることなのですが、その作った張本人は、退社して連絡が取れません。仕様書類は、一切なく、変数名管理表、フローチャート等は、当然、一切ありません。おまけに、コードには、一切コメントがありません。
上司と顧客のカスタマイズ要求も的を得ず、私自身の改良案も思いつかず、
コードの一部をいじくると全体にどんな影響がでるか分からず、手の出しようがありません。
とりあえず、今は、何らかのプログラムの流れが分かる図を書き起こそうと
思うのですが、どのような図を書き起こせば良いか分かりません。
また、私の実力では、何図といわれても、すぐに書き上げるだけの実力がありません。
とにかく、イベントドリブン型のＶＢのコードでは、上から下へ、素直に、イベントプロシージャ、サブプロシージャが記述されておらず、コードの判読に大変な時間がかかる上に、なかなか、理解できません。
どなたか、良い解決方法に限定せず、ご自身の経験談でも、よいので、回答いただける幸いです。宜しくお願いします。

回答No.8

ultraCS

もう、半リタイヤなので

大変ですね、コメントもまともにかけない馬鹿のプログラムをいじるのは

基本として、細部から見ていった方がいいですよ。少なくとも全体像を把握することなどは二の次です。
実際問題として、顧客の要求のほとんどは細部の改良ですから、そのためにどこをいじるかに特化して考えた方がよいです。それですまないようなら、プロジェクトを見直して、組み直した方が早くすむ(能力にもよります)ことも珍しくありません。

イベントドリブンであれば、少なくともイベント単位では独立したプロシジャになってませんか、もしなって無いなら組み直した方がいいと思いますね。
まあ、非道い目に遭っているのだと思い同情は禁じ得ませんが。

お礼

適切なアドバイスありがとうございます。

「顧客の要求のほとんどは細部の改良ですから」は、目からウロコでした。
全体像の把握は、上司の指示であって、顧客の本当の要求では、ありません。
世の中一般に言われていることと、上司が言うこととが同じだから、
それを守っていた自分がバカみたいです。

回答No.7

process9

process9です。

私のアプローチ方法を書きますね。

まず、外部設計書を起こします。
まず、画面一覧と帳票一覧を作成します
そのあと機能一覧（ボタン、ファンクションキー毎ぐらいでいいでしょうね）を書き出す。
これら機能がなんのためにあるかをその一覧に書き出す。
わからない場合は、ユーザなり上司なりに聞きます。
（この帳票はなにに使うのですか？みたいな）

そのあと各画面と帳票のIN/OUTを書き出します。
具体的には、
どうせ、初期設定ファイル、DB（SQL）、画面入出力項目、帳票出力項目ぐらいなので、
　・各初期設定ファイルの設定項目が設定が何に使われているか。
　・DBと画面・帳票の入出力の対応
を調べて書き出します。
このときソースは、あくまでIN/OUTを調べるために読む感じですね。

DBのER図を書きます。ここは、SQLと機能から類推します。
（ちょっと経験値がものいうところですね。）

ここまで、整理すると、システム全体像がようやく見えてくるので、
ここから、上記機能一覧で重要な機能（ボタン？）から、
イベントスタートからソースを追っかけて詳細解析します。
これだとプログラムの上から下への追っかけができるはずです。
デバッグ実行で１行１行追っかけていけばいいはずですから。
その機能に使われている関数の目的、IN／OUT、共通関数の使用、グローバル変数の使用の有無などですね。
これを機能一覧にリンクさせる形式で書き出します。
ここまでやり終えるとほぼ全てが見えます。

システム規模にもよりますが、２０画面１０帳票なら 40H もあれば
つくれるでしょう。

メンテナンスはともかく、カスタマイズになると
ここまで把握しないと触れないはずですし、テストケースが漏れてバグが頻出するはずです。

かならず、ソースの詳細解析は後回しにしても基本設計書（外部設計書）に近いもの作る。この部分で顧客からお金とれないし、時間もとれないといわれるでしょうけど、ソースから全て全体を頭で把握しようとするよりは格段に早いでしょう→メンテナンスやカスタマイズが早くなることで相殺されます。
これが、私の経験上、遠回りのようで最短の道ですね。
また、次の人への引継ぎがスムーズに行えるメリットもついてきます。
（当然カスタマイズ部分の設計書も作るという前提ですが・・・）

お礼

大変、丁寧で、細かいご指摘・ご提案、ありがとうございました。
私のスキルでは、だいぶ時間がかかりそうですが、遠回りのようで最短の道を探ってみたいと思います。
上司にも、顧客にも、基本設計書（外部設計書）の重要性も、ニーズも無いのですが、私自身のスキルアップと、より高給なところへの転職ために、
作成したいと思います。

回答No.6

don_go

私の場合は、他人のプログラムのメンテナンス＆カスタマイズ
は数多くこなしているので、大抵のプログラムはなんとか
なるという感覚でいますが ....

コメントの無いプログラムの場合には、とりあえず

１)モジュールの処理内容、引数、戻り値等のコメント
を入れる。
＃モジュール内の処理の詳細が判らなくても、何の処理
＃をしているモジュールか概要が判るだけでも、全体を
＃把握する助けになります。

２)長い処理の場合には、ブロック毎に適度に改行か、
コメントで仕切りを入れて、読み易くする。
例)
'=====================================

'-------------------------------------

'-------------------------------------

３)解析の済んだ箇所、及びすぐに判ったところから
随時コメントを入れる。

とにかく、最初のうちは細かい所より、全体的な流れが
どうなっているかを把握するようにしましょう。

そうしていくうちに、細かいところも次第に見えてくる
はず.....見えたら良いですね...(^_^;A

思いきって、VBのベテランがいるソフト会社に外注で依頼
した方が早いような気がします。

お礼

大変、丁寧で、細かいご指摘・ご提案、ありがとうございました。

回答No.5

cocodoco5656

とりあえず
関数、イベント
APIを使っているなら
Apiの定義部分を読んで
どれを使っているか確認。
DBもADOかDAOどっちを
どっちを使っているか確認。

お礼

ありがとうございました。

回答No.4

fallen_angel

ＶＢ+WIN32API+データベースの組合せですか。ハードルが高いですね。ＶＢの標準機能だけなら楽なのにね。
　そうですね、、最善策ではありませんが、フォーカスを絞りましょう。
　結果的に自分の首を絞めかねませんが、改良の対象部分の抽出を行ないます。ただスパゲッティＡＰらしいので、それすら難しいかもしれませんね。
　対象を絞る事で、まず作業量が減らせますよね。
　それでも１フォームに５０のアイテムなんて聞くと、嫌になりそうですが、、進めるにはメモ資料を作りながら機能分解しないといけないでしょうね。

　それからウルトラＣで、新規開発の提案ですね。
　改良に見込み工数と新規開発の見込み工数の比較、そして新規開発におけるメリット（例えばＷＥＢベースにしてブラウザで利用できる、またはＯＳやツールの老朽化で今後刷新が避けられないなど、、ですね）を添えて提案ですね。
　ＶＢもＶＢ．ＮＥＴになり機能が追加されているでしょうから、機能・工数・利便性・今後の運用期間などから新規開発の方が効果が出るなら、提案可能です。

お礼

ご回答ありがとうございました。
メモ資料をつくりながら、機能分解に精を出したいと思います。

回答No.3

ipsum11

私の場合は、ひたすらデバック実行！
何度も繰り返しているうちに何をしている処理なのかわかるようになり、その都度ソースにコメントを書き加えていきます。

お礼

回答ありがとうございます。
ですが、もうそれは、やっているのです。
やっているうちに、「自分が馬鹿だから、こんなに時間が、かかっても、先に進まないんじゃないか」という徒労感・情けなさ・失望感・悲観する気持ちが湧き出てきて、その一方で、「最初に作るときに、ＶＢなんだから、外部設計書は簡単につくれるし、スタンドアロンだから、後々のメンテナンスのための書類くらい、簡単に作れたのに、どうして作らなかったんだぁ」という怒りにさいなまれながら、作業をしています。
「こんな職業につくんじゃなかった」とも思います、だから、ＯＫＷａｖｅで実践的なテクニックや体験談を聞きたかったのです。

回答No.2

ttyp03

よくありますね、そういうの。
僕も色々苦労してきました。
今更仕様書を起こしても苦労するだけだし、またそれのメンテナンスに時間を取られてしまうので何か資料を作るのは諦めましょう。
一番いいのはソースをじっくり眺めて全体を把握することですが、コメントがないプログラムは他人が見るとホントに複雑ですね。
そこでポイントを絞ってみていくといいでしょうね。
今回修正する機能はどこのソースに当たるのか。
「Ａ画面のボタンを押した時の機能」なら、そこのソースに行き着くのは容易ですよね。
そしたらそこのソースにだけ集中してください。
そしてそこの箇所での修正方法を考えてください。
もし修正箇所にグローバル変数が出てきてしまったらプロジェクト全体に検索をかけて、その変数を使用している箇所および処理の内容をひとつずつ追っていくしかありません。

と、まあ文章するまでもないことですが、こんな感じでやっていくしかないと思いますよ。
あとは幸いにもVBなのでデバッグ機能を多いに利用してソースの動きをじっくり把握してみてください。

それから最初に「資料は作らない」と書きましたが、余裕があれば何かしらまとめておくと、あとで自分のためになるかもしれません。
自分用のメモ程度でいいので、余裕があればお試しください。
では、がんばってください。

お礼

回答ありがとうございます。
１フォーム画面に、コントロールが50近くついているものもあり、一つの機能（１回の操作）に、集中して、そのソースだけを追いつづけるのも、やってみたのですが、あまりの徒労感に、仕事を放り出したくなる感じです。
普通、分からないことが分かるようになると、「喜び」を感じるのですが、
現在の作業には、それがありません。分かってみると、「（個人的なプログラマーの好みの差があるのでしょうが）どうして、これを実現するのに、こんなスパゲッティなことをして、メンテナンスしづらく作っているんだ」という「怒り」しか、覚えません。でも、ttyp03さんのように、地道にいくことが近道なのでしょうか。僕の性格がひん曲がっているのが、良くないのでしょうか。僕の個人的な印象では、自分で作ったアプリケーションではないので、標準モジュール部で、行なわれている処理に関しては、詳細な資料を作る必要があると感じています。

回答No.1

fallen_angel

まずは、、以下、こんな感じでしょうか？

（１）作成された関数を全て洗い出す。

（２）概要のフローをメインから追う。ＡＰの機能と関数間の関係を把握する。

（３）関数のＩＮ／ＯＵＴの確認。→関数の機能とエラー処理、入出力を把握する。

（４）関数の機能の確認。→場合によっては『関数別にソースファイルを分けて』動作確認する。

お礼

非常に簡潔で分かりやすい、ご指摘・提案をありがとうございます。
但し、私の能力では、ＶＢ+WIN32API+データベースの組合せが、複雑すぎて、うまく切り分けが出来ません。なぜ、WIN32APIの機能を、ここで使っているのかを知りたいがために、ヘルプファイルを使うのですが、WIN32APIのヘルプファイルが現状では、インストールされておらず、原因がわかりません。RDBの構成も、重複が非常に多く、なぜ一つの操作で３つのテーブルに書き込みが必要なのか、判断がつかない場所が多くあります。
「関数機能の切り分けから、デバッグを始めてみてはどうか」というご提案にうまくのって問題の解決に近づければ幸いと考えるのですが、何か良い方策がありましたならば、さらに、アドバイスをいただけると幸いです。