レガシーコードを効果的に使用するための重要なポイントは何ですか？
私は本 レガシーコードで効果的に動作する を数回推奨しました。この本のポイントは何ですか？
ユニット/統合テストを追加してからリファクタリングを行う以外に、レガシーコードを処理する方法は他にありますか？
レガシーコードの主な問題は、テストがないことです。したがって、いくつか追加する必要があります（さらに追加...）。
@mattnzが指摘したように、これ自体は多くの作業を必要とします。しかし、レガシーコードの特別な問題は、テスト可能になるように設計されていないことです。そのため、通常、これはスパゲッティコードの非常に複雑で複雑な混乱であり、ユニットテストする小さなパーツを分離することは非常に困難またはまったく不可能です。したがって、単体テストの前に、コードをリファクタリングして、テストしやすくする必要があります。
ただし、安全にリファクタリングするために、ユニットテストを実行して、変更によって何も壊れていないことを確認する必要があります...これが問題ですレガシーコードの22。
この本では、最初の単体テストを有効にするためだけに、コードに最小限の安全な変更を加えることで、この問題を回避する方法を説明しています。これらは、デザインをより良くするためのものではなく、単体テストを有効にするためだけのものです。実際、設計が見苦しくなったり複雑になったりすることがあります。ただし、これらを使用すると、テストを作成できます。ユニットテストを実施したら、自由にデザインを改善できます。
コードをテスト可能にするためのトリックはたくさんあります。いくつかは明白なものですが、まったくそうでないものもあります。本を読まない限り、自分自身について考えたことのない方法があります。しかし、さらに重要なことは、Feathersがwhatでコードユニットを正確にテスト可能にすることを説明していることです。依存関係を減らし、コードにバリアを導入する必要がありますが、2つの理由があります。
- sensing-コードの実行の影響をチェックおよび検証するため、および
- separation-まず最初に、特定のコードをテストハーネスに取り込みます。
依存関係を安全に削除するのは難しい場合があります。インターフェース、モック、および Dependency Injection の導入は、目標としてクリーンでナイスですが、現時点では必ずしも安全ではありません。そのため、通常は、たとえば次のようなメソッドをオーバーライドするために、テスト対象のクラスをサブクラス化する必要がある場合があります。 DBへの直接リクエストを開始します。また、テスト環境で依存関係のクラス/ jarを偽のクラス/ jarに置き換える必要がある場合もあります...
私にとって、フェザーズによってもたらされた最も重要なコンセプトはseamsです。 シームは、コード自体を変更せずにプログラムの動作を変更できるコード内の場所です。コードにシームを組み込むと、テスト中のコードをseparatingできるようになりますが、senseテストが困難または不可能な場合でも、テスト中のコードの動作を可能にします。直接行う（たとえば、呼び出しが別のオブジェクトまたはサブシステムを変更するため、その状態がテストメソッド内から直接クエリできないため）。
この知識により、最も厄介なコードヒープのテスト容易性の種に気付き、そこに到達するための最小限の、最も中断が少なく、最も安全な変更を見つけることができます。言い換えれば、気付かないうちにコードが壊れるリスクがある「明白な」リファクタリングを作成しないようにするためですyetしないため、ユニットテストでそれを検出します。
の重要なポイントをすばやく取得する方法レガシーコードで効果的に機能する
- 本の2年前に書かれたMichael Feathersの 12ページのPDF を読んでください。
- Michael Feathersのプレゼンテーションを見てください： 68スライド
- Michael Feathersのポッドキャストインタビューを聞いてください。例えば。これは 分のヘンゼル分のエピソード です。
私は数百万行のコードベースの作業を行っており、その一部は1980年代にさかのぼります。それは単なるソフトウェアであるため、いくつかの単体テストを作成するだけで済むため、リファクタリングを行って、それを大幅に改善することができます。
ここでの重要な単語はただのことです。これは、レガシーシステムで作業しているものはもちろんのこと、どのプログラマーの語彙にも属さない4文字の単語です。
1時間の開発作業をテストするために、単体テストを書くのにどれくらい時間がかかると思いますか？議論のために、もう1時間としましょう。
その100万ラインの20年前のレガシーシステムにどれだけの時間が費やされていますか？たとえば、20年間で20人の開発者が2000時間/年を掛けたとしましょう（かなり懸命に働きました）。今度は数を選んでみましょう-新しいコンピューターと新しいツールがあり、そもそもこの$％^^の作品を書いた人よりもはるかに賢いです-あなたはそれらの10の価値があるとしましょう。あなたは40人年を手に入れましたか？
だからあなたの質問への答えははるかにたくさんあるということです。たとえば、1000行のルーチン（5000行を超えるものもいくつかあります）は非常に複雑で、スパゲッティの一部です。 （さらに4文字のWordで）数日かけて数百行のルーチンと数行の20行ヘルパーにリファクタリングするだけですよね？違う。これらの1000行に隠されているのは100のバグ修正で、それぞれが文書化されていないユーザー要件または不明瞭なEdgeケースです。元の100行のルーチンがその仕事をしなかったので、それは1000行です。
「 壊れていない場合は修正しないでください 」という考え方で作業する必要があります。それが壊れているとき、あなたはそれを修正するときに非常に注意する必要があります-あなたがそれをより良くするにつれて、誤って他のものを変更しないようにします。 「壊れた」には、システムとその使用方法に依存する、保守はできないが正しく機能するコードが含まれる場合があることに注意してください。 「私がこれを台無しにしてさらに悪化させたらどうなるか」と尋ねてください。いつの日かあなたはそうするでしょう、そしてあなたはなぜあなたがそうすることを選んだのかを上司の上司に言わなければならないでしょう。
これらのシステムは常により良くすることができます。あなたは仕事をするための予算、タイムライン、何でも持っているでしょう。そうでない場合-行って作成してください。お金/時間がなくなったら、それをより良くするのをやめてください。機能を追加し、少し改善するための時間を確保してください。バグを修正します-もう一度、少し余分な時間をかけて、改善してください。あなたが始めたときよりもそれを悪化させないでください。
本から取り除かなければならない2つの重要なポイントがあります。
- レガシーコードは、テストカバレッジを持たないコードです。
- レガシーコードを変更する必要があるときはいつでも、それがカバレッジを持っていることを確認する必要があります。
他のレスポンダーが指摘しているように、既存のレガシーコードを事前に更新しようとするのは 愚か者の用事 です。代わりに、（新機能やバグ修正のために）レガシーコードを変更する必要がある場合は、時間をかけてレガシーステータスを削除してください。
本当のことを言えば、シェルと言えば、テストの追加とリファクタリングがすべてです。
しかし、この本は、テストして安全にリファクタリングすることが非常に困難なコードを使用して行うためのさまざまなテクニックを提供します。