複雑なレガシーアプリに新しいバグを導入する確率を下げるために、どのようなアプローチを取ることができますか？

私が作業する場所では、コードが完全なスパゲッティである古いシステム（.NET 1）で開発（およびバグ修正）しなければならないことがよくあります-変​​数名、プログラム構造、コメントはほとんど考慮されていません。

このため、どのビットを変更する必要があるかを理解するには年齢がかかります。変更を加えたため、既存のソフトウェアを「壊す」ことがよくあります。私は本当に（同僚と）数か月かけてリファクタリングするのに費やしたいのですが、既存の開発者はどちらもニーズを理解できず、これに時間をかけることもできません（システムは巨大です）。

私が何かを修正するのに数日かかるので、私が他の何かを壊したことを発見するのに数日かかるので、私はそのコードに取り組む必要があることを恐れています。これは明らかに私を無能に見えるようにします-それで私はこれにどのように対処できますか？

作業中のパーツのテストを書き始めます。次のようなワークフローを試すことができます。

1. 変更するパーツのテストを作成します。これは、既存のコードの動作を理解するのにも役立ちます。
   • 必要に応じてテストをサポートするようにコードをリファクタリングしますが、時間が短い場合は非ユニットテストを記述できます。
2. テストを実行して、期待どおりに機能していることを確認します。
3. 変更を加えます。継続的なコード改善の精神で必要に応じてリファクタリングしますが、夢中にならないでください。
4. テストを再実行して、同じ機能を維持していることを確認してください。

テストを破棄しないと、時間の経過とともに、アプリケーションの最も重要な（および/または揮発性の）部分をカバーするテストスイートが構築され、変更を簡単かつ安全に行うことができます。

また、Michael Feathersによるレガシーコードの効果的な使用も役立つかもしれません。

私は従うのが好きアンクルボブ・マーティンのボーイスカウトのルールを：

「大きな乱雑な旧式の札束があるとき、あなたがしなければならないのは...混乱を作るのをやめ、それらを片付け始めることです。

これは、マネージャーを会議室に呼び、コードをリファクタリングしている間、今後3か月間は機能を提供しないことを伝えるという意味ではありません。こんなことしないで！むしろ、「ボーイスカウトルール」を採用して、各モジュールをチェックアウトするときよりも少しクリーンにチェックすることを意味します。

イテレーションからイテレーションまで、そしてリリースからリリースまで、このシステムに新しい機能を追加しながら、システムをクリーンアップします。他に方法はありません。」

何時間もかかるはずの修正は、コードベースの混乱により数日かかることをマネージャーに説明できます。他の開発者は、元の開発者であればリファクタリングの必要はありません。システムを完全に理解していますが、管理者は、それらの開発者が離れて知識を持っている場合にリスクがあることを知っているはずです。

完全なリファクタリングを行うことは通常は実行可能ではないため、一度に小さなビットをリファクタリングすることがよくあります-いくつかのメソッドまたはモジュール。修正するのに数日かかる場合は、問題のあるモジュールの小さなリファクタリングを同時に含めることができます。

コードをリファクタリングするのに何ヶ月も費やす必要がありますか？または、変更を加えながらコードをリファクタリングすることもできます。したがって、たとえば、Fooメソッドを変更する必要があると判断した場合、Fooメソッドをリファクタリングする機会を得ることができます。そして、Fooが問題であることを理解するために他の12のメソッドを実行する必要がある場合は、それらのメソッドにコメントを残して、自分または将来の誰かがコードが何をするべきかを知ることができます。もちろん、それはまだスパゲッティコードの山が残っていることを意味しますが、少なくともコードベースを正しい方向に移動して、簡単に自分で行けるようにすることができます。コードをリファクタリングするために数か月の時間を費やすことは大きなセールスになるでしょう。それは、その時間全体にわたってエンドユーザーが望むものを何も提供しないことを意味するからです。

また、単体テストを作成する（または、できれば既存のテストスイートを拡張する）と、誤って何かを壊す可能性が低くなります。

別のヒント。虫が現れたとき、そして包帯を貼った後、そこで止まらないでください！

5つの理由を尋ね、赤い丸薬を飲み、ウサギの穴の深さを確認し、根本原因（およびその下の道）を修正します。

あなたはシステムについて多くを学びます。修正とリファクタリングの優先順位付けに役立ちます。そして、そのようないくつかの旅行の後、スパゲッティのモノリシックヒープを強化するためのいくつかのしっかりした「サポートビーム」があります。

変更が防音であることが絶対的に確実になるまで、古いコードをそのままにしておくこともできます。すべての変更が当てはまる場合は、実行時に変更を切り替えて、新しい回帰バグの場所をすばやく特定できます。

// old code
...

if (!File.ReadAllText("c:\patch_control.txt").Contains("StrangeUIBugFix=0"))
{
    // new code goes here
    ...
}

// old + new code
int someValue = 
    IsEnabled("StrangeUIBugFix") ? a + b :  // new code
    a * b; // old code

ひとこと： Never change any existing code if you are not sure what effect change would have on complete application.