refactoring - リファクタリングの制限は何ですか?

Question

私は、既存のソフトウェア アーキテクチャを改善する上でのリファクタリングの制限について調査しています。目標を達成するにはリファクタリングが不十分である、またはまだ未熟であると感じた経験をお聞きしたいと思います。

Answer 1

リファクタリングにはリスクが伴う

多くの場合、リファクタリング担当者は元の設計者と同じ人物ではないため、リファクタリングは困難です。したがって、彼または彼女は、システムと元の設計の背後にある決定について同じ背景を持っていません。元の設計で回避されたバグが新しい設計に忍び寄るリスクは常にあります。

これは、このシステムに十分に慣れていない新しいまたは若いチームメンバーが、新しいクールなウィズバンテクノロジーまたはアイデアを安定したシステムに注入することを決定した場合に特に当てはまります。多くの場合、新しいチーム メンバーがチームにうまく統合されておらず、十分なガイダンスが与えられていない場合、チーム全体が意図しない方向にプロジェクトを進め始める可能性があります。

これは単なるリスクですが、チームが間違っている可能性もあり、新しいチームメンバーが担当して自分の仕事をすることが許可された場合、実際には深刻な改善をもたらす可能性があります.

これらの問題は、レガシー システムで作業しているチームでよく発生します。多くの場合、世界を変える機能強化は計画されていないため、チームは設計に保守的です. 彼らの目標は、新しいバグが挿入されるのを防ぎ、いくつかの追加機能を投入して古いバグを修正することです。新しいチームメンバーがやって来て、コードの特定のサブシステムを書き直すと主張してアップルカートを混乱させる可能性があります。新しいバグが作成され、かなり安定した製品のユーザーは、そこから見たソフトウェアが最悪になっているために動揺します。

そのため、主要な機能の変更を伴わない長期的な安定性が目標である場合、多くの場合、主要なリファクタリングは望ましくありません。

ただし、パイクに大きな機能変更があり、製品がまだ完全に完成していないことを期待するユーザーベースを持っている場合 (つまり、ある種のベータ版にいる場合)、深刻なリファクタリングを検討する方がはるかに良い状況です。優れたデザインの長期的なメリットが報われ、大規模なユーザー ベースを混乱させる可能性が低くなります。

Answer 2

対応する単体テストのセット スイートを持たないコードのリファクタリングは、危険を伴う可能性があります。プロジェクトに既に確立された単体テスト スイートがある場合、TDD アプローチを維持していれば、心配する必要はほとんどありません。

Answer 3

あなたの質問が有効かどうかはよくわかりません。あなたはリファクタリングの限界について尋ねています。ただし、リファクタリングにはコードの書き換えが伴います。書き換えるものにどのように制限を設けることができますか? 大規模なリファクタリングの過程で、古いコードを少しずつ完全に置き換えることができます。事実上、元のコードを 1 文字も残さずにリファクタリングを終了できますが、これは極端なことです。リファクタリングの可能性の限界を考えると、どのように制限があると想定できますか? すべての最終コードがまったく新しいものである可能性がある場合、最終コードをゼロから作成した場合と同じように制限はありません。ただし、同じ結果のコードをゼロから作成すると、先に進むための基礎が少なくなり、反復開発の機会が少なくなるため、私は逆の質問で答える必要があります。

Answer 4

すべてのマネージャーがリファクタリングのアイデアを好むわけではありません。彼らの目には、リファクタリングにかかる​​時間は、新しい機能を追加するために使われていません。したがって、マネージャーに必要であることを納得させるか、機能を追加するときに非表示にする必要があります。

したがって、リスクはリファクタリングに時間がかかりすぎることです。

Answer 5

クラスの外部インターフェイスを変更できない場合、リファクタリングで 1 つの問題が発生します。このような場合、リファクタリングできるものは非常に限られています。

Answer 6

Kev の優れた回答 - Michael Feathers による「Working Effectsly with Legacy Code」は、ソフトウェア エンジニアリングに携わる人々に必読です。