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


11

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

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


2
必要なリファクタリングを実行できるテストが実施されていますか?

2
あなたは自分で答えました。クライアントは、コード自体が成果物でない限り、コードの保守性を気にしません。彼らはお金と時間を気にかけ、与えられた品質を引き受けます。品質、時間、コストは技術的負債に直接関係しますが、彼らが受け入れる意思に関連しています。リファクタリングを組み込まない場合、コードの保守性が低下し、技術的な負債は衰えずに急増します。
maple_shaft

回答:


17

絶対に。

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

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

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

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


1
特にクライアントのリファクタリングの価値に関するパラグラフについては+1。
マルジャンヴェネマ

1
リファクタリングを検証するための適切な一連の単体テストがあると仮定すると、観察される動作は変わりません。再現テストまたは単体テストの選択を考えます。最初に単体テストを追加します。
マーティンヨーク

5
@Thomas Owens:+1同意しますが、リファクタリングに関する注意書きも追加します。リファクタリングは、必要な実際の作業を膨張させ、期限を急上昇させるリファクタリングのカスケードを開始するのは非常に簡単です。
ジョエルイーサトン

@ジョエルそれは良い点です。期限を設定するには、リファクタリングの範囲を制限する必要があります。
トーマスオーエンズ

3

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

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

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

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

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

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

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

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

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

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

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


あなたは私の心を読んだ!リファクタリングを延期することを正当化するために、「壊れていない場合は修正しない」という有名なルールを正確に考えていました!
カルロスハイメC.デレオン

3

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

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

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

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

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


2

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

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

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

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


0

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

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.