仕事で、ソフトを新規で作ったり、元あったソフトを改造したりしています。
VB.netでやっていて、プログラミングを初めて現在7か月ほど経過しています。
新規作成の部分は、難なくこなせるのですが、改造の案件が来た時に苦戦してしまいます。
(改造の案件は社内の別の人が作ったものです。)
改造するときに気を付けた方がいいことなどありますでしょうか?
また改造に着手するとき、何から着手すればよいでしょうか?
ご意見お待ちしております。
気になる質問をクリップする
クリップした質問は、後からいつでもMYページで確認できます。
またクリップした質問に回答があった際、通知やメールを受け取ることができます。
回答3件
#1
総合スコア12342
投稿2026/01/06 10:37
編集2026/01/06 10:39何から着手
元のやつの{動作,作り,etc}を必要なだけ把握する
改造するときに気を付けた方がいいこと
手の加え方に関して「もっと影響範囲を狭くできる方法が無いのか?」を可能な限り考える.
あと,「まだ途中だけど,だいたいこんな感じになる想定だけどOK?」みたいな確認をとれるならば,こまめにやる.
(社内がどうこう~とか書かれているので,そういうことが可能なんじゃないかと思うので)
#2
総合スコア1663
投稿2026/01/06 16:40
改造の際に気をつけるのは、改造しない既存の機能が今まで通り正常に動くことです。
動かなくなることを「デグレード」とか「リグレッション」とか言います。
(意味は同じ。人によって言い方が異なる。)
そのためには、改造前後でソース差分の行数が一番少なくなる修正を心がけましょう。
レビューもテストもしやすくなります。
全く別の考え方もあって、改造箇所を含む機能とか画面とかを丸ごと作り直す方法もあります。
既存の機能は変えずにソースをきれいにすることで、「リファクタリング」と言います。
どちらが正しいかは、修正の規模や期間、元のソース解析にかかる時間、TestRunnerを用意しているか等にもよります。
ある程度、見積もりができたら、上司に方向性を相談してから作業を進めましょう。
#3
総合スコア86522
投稿2026/01/07 10:04
新規作成の部分は、難なくこなせるのですが、改造の案件が来た時に苦戦してしまいます。
苦戦する理由はいろいろあり得るので、あなたの場合どういう理由で苦戦しているのかを分析して、それへの対応策を考えて実施するのが良いと思います。一般論は無いです。
何でもそうですが、「うまくいかない原因」がわからないと、改善できません。
また改造に着手するとき、何から着手すればよいでしょうか?
これも、どんなシステムであるのかによって、いろいろな考え方があるかと思います。
以下は、一例ですが、あなたの場合に適用できるのかどうかは不明です。
そのシステムをゼロから作るときと同じく、どういう業務をどのようにシステムで支援するのかということを理解するのが最初でしょう。そのシステムの目的ですね。これはまあ聞けばわかるでしょう。
ゼロから作るのでなくて改造で対応するので、そのシステムの目的のために、前任者はどのようなアプローチで、どのように設計したのかを調べるのが次。これは良いドキュメントが残ってない場合が多い気がします。リバースエンジニアリングツールがうまく使えればいいのですが。
で、コードを読んで理解する。
もちろん、微細な修正であれば、前段を飛ばして、該当のプログラムを読むだけでできると思います。
変更要件と状況によっては全面再構築も検討した方がいいかもしれない。
他に考えるべきこととしては、
・「ここだけ修正すればいいと思って修正・テストしてリリースしたけど、実際に障害が発生して、あそこも修正が必要だったことが分かった」みたいなことをどう防ぐか。
・テストをどの範囲行うか。修正規模によっては、システム新規作成時と同じ規模のテストが必要かもしれません。
・なじみのないシステムだと、プログラムが正しくても、本番システム修正手順を間違えてしまって障害発生とかも。自動化されていれば細かい間違いはないのでしょうが。
など。
あなたの回答
tips
太字
斜体
打ち消し線
見出し
引用テキストの挿入
コードの挿入
リンクの挿入
リストの挿入
番号リストの挿入
表の挿入
水平線の挿入
プレビュー
質問の解決につながる回答をしましょう。 サンプルコードなど、より具体的な説明があると質問者の理解の助けになります。 また、読む側のことを考えた、分かりやすい文章を心がけましょう。