質問するログイン新規登録

意見交換

3回答

308閲覧

ソフトの改造について。

osechikappamaki

総合スコア1

VB

VB(ビジュアルベーシック)はマイクロソフトによってつくられたオブジェクト指向プログラミング言語のひとつで、同社のQuickBASICが拡張されたものです。VB6の進化版といわれています。

C++

C++はC言語をもとにしてつくられた最もよく使われるマルチパラダイムプログラミング言語の1つです。オブジェクト指向、ジェネリック、命令型など広く対応しており、多目的に使用されています。

VB.NET

Microsoft Visual Basic .NETのことで、Microsoft Visual Basic(VB6)の後継。 .NET環境向けのプログラムを開発することができます。 現在のVB.NETでは、.NET Frameworkを利用して開発を行うことが可能です。

0グッド

0クリップ

投稿2026/01/06 07:41

0

0

仕事で、ソフトを新規で作ったり、元あったソフトを改造したりしています。

VB.netでやっていて、プログラミングを初めて現在7か月ほど経過しています。
新規作成の部分は、難なくこなせるのですが、改造の案件が来た時に苦戦してしまいます。
(改造の案件は社内の別の人が作ったものです。)

改造するときに気を付けた方がいいことなどありますでしょうか?
また改造に着手するとき、何から着手すればよいでしょうか?

ご意見お待ちしております。

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

回答3

#1

fana

総合スコア12342

投稿2026/01/06 10:37

編集2026/01/06 10:39

何から着手

元のやつの{動作,作り,etc}を必要なだけ把握する

改造するときに気を付けた方がいいこと

手の加え方に関して「もっと影響範囲を狭くできる方法が無いのか?」を可能な限り考える.

あと,「まだ途中だけど,だいたいこんな感じになる想定だけどOK?」みたいな確認をとれるならば,こまめにやる.
(社内がどうこう~とか書かれているので,そういうことが可能なんじゃないかと思うので)

#2

hiroki-o

総合スコア1663

投稿2026/01/06 16:40

改造の際に気をつけるのは、改造しない既存の機能が今まで通り正常に動くことです。
動かなくなることを「デグレード」とか「リグレッション」とか言います。
(意味は同じ。人によって言い方が異なる。)

そのためには、改造前後でソース差分の行数が一番少なくなる修正を心がけましょう。
レビューもテストもしやすくなります。

全く別の考え方もあって、改造箇所を含む機能とか画面とかを丸ごと作り直す方法もあります。
既存の機能は変えずにソースをきれいにすることで、「リファクタリング」と言います。

どちらが正しいかは、修正の規模や期間、元のソース解析にかかる時間、TestRunnerを用意しているか等にもよります。
ある程度、見積もりができたら、上司に方向性を相談してから作業を進めましょう。

#3

otn

総合スコア86522

投稿2026/01/07 10:04

新規作成の部分は、難なくこなせるのですが、改造の案件が来た時に苦戦してしまいます。

苦戦する理由はいろいろあり得るので、あなたの場合どういう理由で苦戦しているのかを分析して、それへの対応策を考えて実施するのが良いと思います。一般論は無いです。
何でもそうですが、「うまくいかない原因」がわからないと、改善できません。


また改造に着手するとき、何から着手すればよいでしょうか?

これも、どんなシステムであるのかによって、いろいろな考え方があるかと思います。
以下は、一例ですが、あなたの場合に適用できるのかどうかは不明です。

そのシステムをゼロから作るときと同じく、どういう業務をどのようにシステムで支援するのかということを理解するのが最初でしょう。そのシステムの目的ですね。これはまあ聞けばわかるでしょう。
ゼロから作るのでなくて改造で対応するので、そのシステムの目的のために、前任者はどのようなアプローチで、どのように設計したのかを調べるのが次。これは良いドキュメントが残ってない場合が多い気がします。リバースエンジニアリングツールがうまく使えればいいのですが。
で、コードを読んで理解する。
もちろん、微細な修正であれば、前段を飛ばして、該当のプログラムを読むだけでできると思います。
変更要件と状況によっては全面再構築も検討した方がいいかもしれない。


他に考えるべきこととしては、
・「ここだけ修正すればいいと思って修正・テストしてリリースしたけど、実際に障害が発生して、あそこも修正が必要だったことが分かった」みたいなことをどう防ぐか。
・テストをどの範囲行うか。修正規模によっては、システム新規作成時と同じ規模のテストが必要かもしれません。
・なじみのないシステムだと、プログラムが正しくても、本番システム修正手順を間違えてしまって障害発生とかも。自動化されていれば細かい間違いはないのでしょうが。
など。

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

この意見交換はまだ受付中です。

会員登録して回答してみよう

アカウントをお持ちの方は

関連した質問