refactoring - レガシーコードの悪夢

Question

私は、クラス図がスパゲッティの皿の上のクモの巣によく似ているプロジェクトを継承しました。私は過去 2 か月で約 300 の単体テストを作成し、メインの実行可能ファイルをカバーするセーフティネットを自分自身に与えました。

私は、アジャイル開発に関する書籍のライブラリをいつでも手の届くところに置いています。

レガシコードを効果的に使用する
リファクタリング
コードコンプリート
C# でのアジャイル原則のパターンとプラクティス
等

問題は、私が触れるものすべてが他の何かを壊しているように見えることです. UI クラスには、ビジネスロジックとデータベースコードが混在しています。多数のクラス間に相互依存関係があります。他のクラスを変更するたびに壊れる神のクラスがいくつかあります。また、約半分のインスタンスメソッドと半分の静的メソッドを持つミュータントシングルトン/ユーティリティクラスもあります (皮肉なことに、静的メソッドはインスタンスに依存し、インスタンスメソッドは依存しません)。

私の前任者は、すべてのデータセットを逆方向に使用するのが賢明だとさえ考えていました。すべてのデータベースの更新は、ストアドプロシージャのパラメーターとして db サーバーに直接送信され、データセットは手動で更新されるため、UI には最新の変更が表示されます。

私は時々、彼らが仕事の安全のために、あるいはコードを引き渡す前の最後の別れとして、ある種の弱い難読化を使用したのではないかと考えたくなることがあります。

この混乱を解消するための良いリソースはありますか? 私が持っている本は役に立ちますが、私が直面しているシナリオの半分しかカバーしていないようです.

score 24 · Accepted Answer

適切な方法で対処しているようです。

テスト
リファクタリング
再テスト

残念ながら、これは時間のかかる退屈なプロセスになる可能性があります。コードが何を達成しようとしているのかを掘り下げて理解することに代わるものはありません。

私がお勧めできる 1 本 (「etc.」の下にまだ提出されていない場合) はRefactoring to Patternsです。それはあなたの正確な状況にある人々を対象としています。

score 19 · Accepted Answer

私も似たような状況で働いています。

それが小規模なユーティリティではなく、大規模なエンタープライズプロジェクトである場合は、次のようになります。

a) 修正するには遅すぎる
b) 1 人の人間が試みる能力を超えている a)
c) 問題外のものを完全に書き直すことによってのみ修正できる

多くの場合、リファクタリングは、個人の責任においてプライベートな時間にのみ試みることができます。日常業務の一部としてそれを行うという明確な命令を受けていない場合は、それに対する功績すら認められない可能性があります。「すでに長い間完全に機能していたものに無駄に時間を浪費している」と批判されることさえあります.

以前にハッキングされたのと同じようにハッキングを続けて、給料を受け取ってください。完全にイライラするか、システムがこれ以上ハッキングできなくなったら、別の仕事を見つけてください。

編集: 私が真のアーキテクチャの問題に取り組み、物事を正しい方法で実行しようとするときはいつでも、「私は良いアーキテクチャについて気にしない」(試みたドイツ語からの翻訳）。私は個人的に 1 つの非常に悪いコンポーネントをハッキング不可能な状態にしましたが、もちろん何ヶ月も前に事前の警告を出しました。その後、顧客に約束したいくつかの機能をキャンセルする必要がありました。もう誰も触らない…

score 4 · Accepted Answer

私は（一度）非常に絡み合ったコードに出くわしたことがあり、機能的な複製で妥当な時間内に修正できませんでした。ただし、それはパーサーであり、パーサーに含まれるバグの一部を「使用」しているクライアントがどれだけあるかはわかりませんでした。何百もの「動作する」ソースファイルを誤ってレンダリングすることは、適切な選択肢ではありませんでした。

ほとんどの場合、それは差し迫った実行可能であり、気が遠くなるだけです。そのリファクタリングの本を読んでください。

私は一般に、モジュールとクラスが少なくともある程度一貫性を保つように、(必要以上に実装コードを実際に変更することなく) 少し移動することから悪いコードの修正を開始します。

それが完了したら、より首尾一貫したクラスを使用して、まったく同じように実行するように内部を書き直すことができますが、今回は賢明なコードを使用します。管理者は通常、まったく同じように動作するものをコーディングしてデバッグするのに何週間もかかるということを聞きたがらないため (すべてがうまくいけば)、これは管理の難しい部分です。

このプロセス中に、大量のバグやあからさまな設計の愚かさを発見することを保証します。再コーディング中に些細なバグを修正することは問題ありませんが、それ以外の場合は後回しにします。

いくつかのクラスでこれが完了すると、どこをより適切にモジュール化できるか、より適切に設計できるかなどがわかります。さらに、コードがよりモジュール化されているため、関係のないものに影響を与えることなく、そのような変更を行うことが容易になります。よくわかっているのだろう。

score 1 · Accepted Answer

リファクタリングによって問題が発生している場合は、ユニットテストが最初に壊れているはずなので、十分なユニットテストカバレッジがないことを意味します。例外のログ記録を適切に行った後、2 番目に単体テストのカバレッジを改善することをお勧めします。

次に、最初に小さなリファクタリングを行うことをお勧めします - メソッドを抽出して、大きなメソッドを理解できる断片に分割します。変数を導入して、メソッド内の重複を削除します。呼び出し元と呼び出し先で使用される変数の間に重複が見つかった場合は、パラメーターを導入してください。

そして、各リファクタリングまたは一連のリファクタリングの後に単体テストスイートを実行します。どのテストを毎回再実行する必要があるかについて確信が持てるまで、それらすべてを実行することをお勧めします。

score 1 · Accepted Answer

ブログ投稿の Anatomy of an Anti-Corruption Layer, Part 1およびAnatomy of an Anti-Corruption Layer, Part 2を参照してください。

ドメイン駆動型設計: ソフトウェアの中心部での複雑さへの取り組み:

ファサードの背後にあるがらくたにアクセスする

score 0 · Accepted Answer

その一部を抽出してリファクタリングし、依存関係を解消して、レイヤーをさまざまなモジュール、ライブラリ、アセンブリ、ディレクトリに分離することができます。次に、ストラングラーアプリケーション戦略を使用して、クリーニングしたパーツをアプリケーションに再注入します。泡立てて、すすぎ、繰り返します。

score 0 · Accepted Answer

次の投稿が役立つかもしれません：http： //refactoringin.net/ ？p = 36

投稿で述べられているように、完全な上書きを簡単に破棄しないでください。また、可能であれば、レイヤーまたはティア全体を、永続性のためのORMや新しいコードなどのサードパーティソリューションに置き換えてみてください。しかし、何よりも重要なのは、コードの背後にあるロジック（問題ドメイン）を理解することです。

score 0 · Accepted Answer

Code Completeの図が特に気に入っています。この図では、ファジーグレーテクスチャの長方形であるレガシーコードだけから始めます。次に、その一部を置き換えると、下部がぼやけた灰色になり、上部が白一色になり、2 つの境界を表すギザギザの線が表示されます。

つまり、すべてが「厄介な古いもの」か「素敵な新しいもの」のどちらかです。ラインの片側または反対側。

システムのさまざまな部分をさまざまな速度で移行しているため、線がギザギザになっています。

作業を進めると、ギザギザの線が徐々に下がり、灰色よりも白が多くなり、最終的には灰色になります。

もちろん、それで詳細が簡単になるわけではありません。ただし、進捗状況を監視するために使用できるモデルが得られます。どのビットが新しいか、どのビットが古いか、2 つの側がどのように通信するかなど、いつでも回線がどこにあるかを明確に理解しておく必要があります。

score 0 · Accepted Answer

幸運を祈ります。それは開発者にとって大変な部分です。

あなたのアプローチは良いと思いますが、ビジネス価値の提供に集中する必要があります (単体テストの数はビジネス価値の尺度ではありませんが、軌道に乗っているか外れているかを示す可能性があります)。変更が必要な行動を特定し、優先順位を付け、上位のものに焦点を当てることが重要です。

もう 1 つのアドバイスは、謙虚でいることです。本当の期限内に非常に大きなものを書き、他の誰かがあなたのコードを見た場合、彼らもおそらくそれを理解するのに苦労するでしょう. きれいなコードを書くスキルもあれば、他の人のコードを扱うスキルも重要です。

最後のアドバイスは、チームの他のメンバーを活用することです。過去のメンバーは、あなたが学べるシステムに関する情報を知っているかもしれません。また、動作のテストに役立つ場合もあります。テストを自動化することが理想であることは承知していますが、手動で検証することで誰かが助けてくれる場合は、彼らの助けを借りることを検討してください。

refactoring - レガシーコードの悪夢

13 に答える 13

Related

Reference