新機能に焦点を当てたプロジェクトで壊れていない既存のコードをリファクタリングする必要がありますか？
アプリケーションに新しい機能を追加することを目的とする小さなプロジェクトを考えると、導入された変更は既存のコードに影響を与え、特定の領域でこれらを更新する必要があります。実装中に、更新されたこれらのコードの一部にリファクタリングの候補があることがわかりました。
これは、影響を受けるコンポーネントの回帰テストを必要とするリファクタリングに適切な時期ですか（そのため、元々プロジェクトの一部ではないスコープが導入される可能性があります）？または、延期して機能を完了し、おそらくリファクタリングのための個別のプロジェクトを用意する必要があります（ただし、コードの保守性を重視しない限り、ビジネスユーザーが機能を追加しないプロジェクトを完全に後援しているわけではないため、少しためらっています...）？
もちろんです。
リファクタリングは、作業中の「合格」プロジェクトで行う必要があります。すべてのテスト（ユニット、システム、許容レベル）に合格すると、製品が要件を満たしていることがわかります。リファクタリングすると、すべてのテストが引き続き成功することを確認できます。いずれかのテストが失敗し始めた場合、何か問題があり、修正する必要があります。失敗したテストがある場合は、リファクタリングの前にそれらを修正して、リファクタリングによってシステムの機能が変更されないようにする必要があります。
これは、リファクタリングを実行するための時間とリソースがあり、時間と予算を守ることができる場合、リファクタリングに最適な時間でもあります。リファクタリングを行うと、システムの理解と保守が容易になるため、さらに新しい機能を追加すると、簡単になります。 code rot および software entropy と戦う必要があります。
Joel Etherton がコメントで指摘しているように、リファクタリングの範囲を管理する必要があります。すぐに機能を追加するシステムの部分のリファクタリングに焦点を当て、新しい機能の操作や追加を容易にするリファクタリングを実行します。静的分析、メトリックツール、およびコードレビューを使用すると、最も重要な領域を特定するのに役立ちます。リファクタリングを行っているので、期限を逃したくない-それでも顧客に付加価値を付け続ける必要があります。
あなたはリファクタリングに価値を見いだしていない顧客に言及します。通常、顧客はコードの品質ではなく製品の品質を気にしません。リファクタリングを使用すると、高品質の製品を維持しやすくなり、顧客の変化するニーズを満たす製品を提供し続けることができます。スケジュールにリファクタリングする時間について交渉するようにしてください（お客様はY日間にX機能が必要です。Y+ Z日またはXN機能を取得できないため、設計、リファクタリング、および実装に時間を費やすことができるかどうかを確認してください）。できる。
すぐにリファクタリングし、頻繁にリファクタリングします。
余裕があれば（時間、お金など）それをすべきです。
時々、時間切れになる可能性がある、またはコード保守の介入のためにお金がもらえない、またはプロジェクトをできるだけ早く完了したい、またはリファクタリングにはリソースが必要なため一般的にそうなるためです。しかし、それを除けば、常にリファクタリングを行う良い機会です。
最新のコードが必要であり、特に新しい機能を追加するときにコードに実際に変更が必要だと思われる場合は、コードを変更する必要があります。
現在のコードにまったく影響を与えないように、プロジェクトを新しいブランチにフォークできるバージョン管理システムを忘れないでください。
以下の質問に答えることを検討してください。そうすれば、簡単に決定できます。 「壊れていないなら直さない」という知恵は魅力的ですが、プロの仕事には必ずしも当てはまりません。
0-このコードについて顧客から苦情はありますか？
1-これはアプリケーションの機能に必要ですか
2-現在のコードは有害ですか？
3-変更のコストはそれだけの価値がありますか？
4費用は余裕がありますか？
5-これはあなたのスキルを組織に活用するのに最適です
6-変更により、ユーザーは新しい変更を再インストールする必要がありますか-それを顧客に正当化できますか？
7-悪い修正のリスクを許容できますか？
8-変更はプロジェクト外の他のコードに影響しますか？
9-これは進化する製品ですか、それとも安定した製品ですか？進化している場合、次のリリースに変更を含めることができますか？
新しい機能を実装するためにリファクタリングが必要な場合、それは新しい開発の一部として行われ、考慮されるべきです。
コードが重複していると、ある場所で編集が行われ、別の場所では編集が行われないため、長期的には（個人的にも会社にとっても）コストがかかります。
既存の機能に問題が生じていないことを証明する一連のテスト（自動化された単体テストまたは実行可能な回帰テスト）が必要です。
リファクタリングが単に「やるべきこと」である場合、つまり、新しい機能によって直接影響を受けるコードに含まれていない場合は、そのままにしておきます。変更のために変更を導入しています。
コードをリファクタリングすると、新しい機能を簡単に追加できるようになります。それが理論です。これを新機能の範囲に含めます。この方法でビジネスユーザーから賛同を得られる可能性が高くなります。この場合、説得力のある議論を行い、リファクタリングの時間を正当化できるはずです。うまくいけば、これが開発プロセスの必要な部分であり、異論が少なくなることを理解するでしょう。この直接的なメリットを常に実証できるとは限りません。