新しい機能に焦点を当てたプロジェクトで壊れていない既存のコードをリファクタリングする必要がありますか？

アプリケーションに新しい機能を追加することを目的とする小さなプロジェクトを考えると、導入された変更は、特定の領域でこれらを更新することを含む既存のコードに影響を与えます。実装中に、更新されたこれらのコードの一部にリファクタリングの候補があることがわかりました。

これは、影響を受けるコンポーネントのリグレッションテストを必要とするリファクタリングの適切な時間ですか（したがって、元々プロジェクトの一部ではないスコープを導入している可能性があります）？または、機能を延期し、機能を完成させ、おそらくリファクタリングのための別個のプロジェクトを用意する必要があります（ただし、ビジネスユーザーは、コードの保守性を重視しない限り、機能を追加しないプロジェクトを完全に後援できないため、少しためらっています...）？

絶対に。

リファクタリングは、作業中の「合格」プロジェクトで実行する必要があります。すべてのテスト（ユニット、システム、および受け入れレベル）に合格すると、製品が要件を満たしていることがわかります。リファクタリングすると、すべてのテストが引き続き合格することを確認できます。いずれかのテストが失敗し始めた場合、あなたは何か間違ったことをし、それを修正する必要があります。テストに失敗した場合は、リファクタリングの前にそれらを修正して、リファクタリングがシステムの機能を変更しないことを常に確認できるようにする必要があります。

また、これはリファクタリングを実行する時間とリソースがあり、それでも時間と予算内で納品できると仮定すると、リファクタリングに最適な時期です。リファクタリングにより、システムの理解と保守が容易になるため、さらに多くの新機能を追加するほど簡単になります。コードの腐敗やソフトウェアのエントロピーと戦う必要があります。

ジョエルEthertonはコメントで指摘し、あなたがリファクタリングの範囲を管理する必要があります。すぐに機能を追加するシステムの部分のリファクタリングに焦点を合わせ、新しい機能の操作や追加を容易にするリファクタリングを実行します。静的分析、メトリックツール、およびコードレビューを使用すると、最も重要な領域を特定できます。リファクタリングを行っていたため、期限を逃したくありません。顧客に付加価値を与え続ける必要があります。

リファクタリングで価値が見られない顧客について言及します。通常、顧客はコードの品質ではなく製品の品質を気にします。リファクタリングにより、高い製品品質を維持し、変化する顧客のニーズを満たす製品を提供し続けることが容易になります。スケジュールにリファクタリングする時間を交渉してみてください（顧客がY日間でXの機能を望んでいる場合、Y + Zの日またはXNの機能を取得できないので、設計、リファクタリング、および実装に時間をかけることができます）できる。

以下の質問に答えることを検討してください。そうすれば、決定を下すのは簡単です。「壊れていなければ修正しない」という知恵は魅力的ですが、プロの仕事には必ずしも当てはまりません。

0-このコードに関するお客様からの苦情はありますか？

1-これはアプリケーションの機能に必要ですか

2-現在のコードは有害ですか？

3-変更のコストはそれだけの価値がありますか？

4-費用はかかりますか？

5-これはあなたのスキルを組織に最適に活用していますか

6-変更により、ユーザーは新しい変更を再インストールする必要がありますか？それを顧客に正当化できますか？

7-悪い修正のリスクを許容できますか？

8-変更はプロジェクト外の他のコードに影響しますか？

9-これは進化中の製品ですか、それとも安定した製品ですか？進化している場合、次のリリースで変更を含めることができますか？

すぐにリファクタリングし、頻繁にリファクタリングします。

余裕があれば（時間、お金など）、それをするべきです。

私はこれを言うのは、時々あなたが時間を使い果たすかもしれない、またはあなたがコード保守介入のためのお金を受け取らないと言うか、またはあなたができるだけ早くプロジェクトを完了したいと思うように、そして一般的にリファクタリングにはリソースが必要なためです。しかし、それとは別に、リファクタリングには常に良い時期です。

最新のコードが必要であり、特に新しい機能を追加するときにコードに実際に変更が必要であると感じた場合は、変更する必要があります。

バージョン管理システムを使用すると、プロジェクトを新しいブランチに実際に分岐できるため、現在のコードにまったく影響を与えないことを忘れないでください。

新しい機能を実装するためにリファクタリングが必要な場合は、新しい開発の一部として実行およびファクタリングする必要があります。

コードが重複していると、編集が1つの場所でのみ行われ、別の場所では行われないため、長期的には（個人的にも会社も）コストがかかります。

既存の機能に問題が発生していないことを証明する自動化された単体テストまたは実行可能な回帰テストのいずれかのテストセットが必要です。

リファクタリングが「やるだけ」の場合、つまり、新しい機能によって直接影響を受けるコード内にない場合は、そのままにしておきます。あなたは変化のために変化を導入しています。

コードをリファクタリングすると、新しい機能を簡単に追加できるように思えます。それが理論です。これを新機能の範囲に含めます。この方法でビジネスユーザーから賛同を得る可能性が高くなります。この場合、説得力のある議論を行い、リファクタリングの時間を正当化できるはずです。これが開発プロセスの必要な部分であり、異議が少ないことを彼らが理解することを願っています。この直接的な利点を常に示すことができるとは限りません。