レガシー コードベースで作業する場合、コードベースの品質を向上させるために時間の経過とともに最も大きな影響を与えるものは何ですか?
コードベースは、さまざまなレベルの専門知識を持つ多くの開発者によって長年にわたって書かれており、多くの領域がテストされておらず、テストの作成にかなりの時間を費やさないとテストできない領域もあります。
これは素晴らしい本です。
その答えが気に入らない場合は、私ができる最善のアドバイスは次のとおりです。
[1]：レガシーコード=単体テストがないため、不明なコード
自動テストスイートを導入せずにレガシーコードを変更することは危険であり、無責任です。ユニットテストのカバレッジが適切でない場合、これらの変更がどのような影響を与えるかを知ることはできません。Feathersは、変更する必要のあるコードの領域を分離し、基本的な仮定を検証するための基本的なテストを作成し、単体テストに裏打ちされた小さな変更を加え、そこから作業を行う「絞首刑」アプローチを推奨しています。
注：すべてを停止し、すべてのテストを作成するために数週間を費やす必要があると言っているわけではありません。まったく逆に、テストする必要のある領域をテストして、そこから作業するだけです。
ジミー・ボガードとレイ・ヒューストンは、これに非常によく似たテーマで興味深いスクリーンキャストを行いました： http：//www.lostechies.com/blogs/jimmy_bogard/archive/2008/05/06/pablotv-elimination-static-dependencies-screencast。 aspx
私は、約 50 人のプログラマーによって作成および変更されたレガシー 1M LOC アプリケーションを使用しています。
* Remove unused code
ほとんど役に立たない...無視してください。そこから大きな投資収益率 (ROI) を得ることはできません。
* Remove duplicated code
実際、何かを修正するときは、常に重複を検索します。いくつか見つかった場合は、ジェネリック関数を配置するか、重複するすべてのコードの出現箇所にコメントを付けます (ジェネリック関数を配置する努力が無駄になる場合があります)。主なアイデアは、同じアクションを複数回行うのが嫌いだということです。もう1つの理由は、他の出来事をチェックするのを忘れている人（私かもしれません）が常にいるからです...
* Add unit tests to improve test coverage where coverage is low
自動化された単体テストは素晴らしいですが、バックログが大きい場合、安定性の問題がない限り、タスク自体を推進するのは困難です。あなたが取り組んでいる部分に行き、数年後にまともな報道があることを願っています.
* Create consistent formatting across files
IMO フォーマットの違いはレガシーの一部です。誰が、いつコードを書いたかについてのヒントが得られます。これにより、コードのその部分でどのように動作するかについての手がかりが得られます。再フォーマットの仕事をするのは楽しいことではありませんし、顧客に何の価値ももたらしません。
* Update 3rd party software
新しい非常に優れた機能がある場合、またはお使いのバージョンが新しいオペレーティング システムでサポートされていない場合にのみ行ってください。
* Reduce warnings generated by static analysis tools
それだけの価値があります。警告によって、潜在的なバグが隠されることがあります。
単体テストを追加して、テストカバレッジを改善します。テストカバレッジが良好であれば、恐れることなく機能をリファクタリングして改善できます。
CPPUnitの作者によって書かれた、これに関する優れた本があります。レガシーコードで効果的に機能します。
レガシーコードにテストを追加することは、最初からテストを作成するよりも確かに困難です。私が本から取り上げた最も有用な概念は、フェザーズが次のように定義する「継ぎ目」の概念です。
「その場所で編集せずに、プログラムの動作を変更できる場所。」
将来のテストを容易にする（またはそもそも可能にする）シームを作成するためにリファクタリングする価値がある場合があります。Googleテストブログには、このテーマに関するいくつかの興味深い投稿があり、主に依存性注入のプロセスを中心に展開しています。
「重複したコードを削除する」とは、コードを取り出して抽象化し、複数の場所で使用できるようにする必要があることを意味します。これにより、理論的には、1 つのコードを修正するだけで済むため、バグの修正が容易になります。 、多くのコードとは対照的に、バグを修正します。
私は現在、私の膝に「それらの」古い学校のコードベースの1つを持っているので、この質問に関連することができます。それは本当に遺産ではありませんが、確かに年の傾向に従わなかった。
彼らが毎日私を悩ませているので、私がそれに修正したいことをあなたに話します：
残りは本当にピーナッツです。これらはレガシーコードベースの主な問題であり、実際に多くの時間を消費します。
レガシーコードで何をしたいかに大きく依存すると思います...
メンテナンスモードが無期限に維持され、正常に機能している場合は、何もしないことが最善の策です。「壊れていない場合は、修正しないでください。」
正常に機能しない場合は、未使用のコードを削除して重複コードをリファクタリングすると、デバッグがはるかに簡単になります。ただし、これらの変更は誤ったコードに対してのみ行います。
バージョン2.0を計画している場合は、単体テストを追加し、転送するコードをクリーンアップします
良いドキュメント。レガシー コードを保守および拡張する必要がある人にとって、これが最大の問題です。理解できないコードを変更することは、まったく危険ではないにしても、難しいことです。幸運にも文書化されたコードを手に入れたとしても、その文書が正しいと確信できるでしょうか? 原作者の暗黙の知識をすべて網羅していると？それがすべての「トリック」とエッジケースに当てはまるということですか?
優れたドキュメントは、元の作成者以外の人が悪いコードであっても理解し、修正し、拡張できるようにするものです。私は、ハッキングされているが十分に文書化されており、完全でありながら不可解なコードよりも理解できるコードをいつでも採用します。
作業しなければならないレガシー コードに対して行った最大の作業は、その周りに実際の API を構築することです。私が .NET オブジェクト モデルを構築したのは 1970 年代スタイルの COBOL API であり、すべての安全でないコードが 1 か所にあり、API のネイティブ データ型と .NET データ型の間のすべての変換が 1 か所にあります。主なメソッドは DataSet を返したり受け入れたりします。
これを正しく行うのは非常に困難であり、私が知っているいくつかの欠陥がまだあります. 進行中のすべてのマーシャリングでは、それほど効率的でもありません。しかし一方で、データを Btrieve に保持する 15 年前のアプリケーション (!) にデータを往復する DataGridView を約 30 分で構築でき、それは機能します。顧客がプロジェクトで私のところに来るとき、私の見積もりは月や年ではなく、日や週です。
ほとんどの場合、そのままにしておくといいでしょう。壊れていない場合は、修正しないでください。壊れている場合は、コードの壊れている部分とそのすぐ周囲のコードを修正して改善します。バグの痛みや欠落している機能を利用して、その部分を改善するための労力と費用を正当化できます。
実際のビジネスやエンドユーザーのニーズに基づいていない大規模な書き換え、リファクタリング、再フォーマット、または単体テストの導入はお勧めしません。
何かを修正する機会が得られた場合は、それを正しく行います (最初に正しく行うチャンスはすでに過ぎている可能性がありますが、その部分に再び触れているので、今度は正しく行う可能性があります)。これにはすべてが含まれます。あなたが言及した項目。
要約すると、あなたがしなければならないことは 1 つまたはいくつかあります。少しずつ、日和見的な方法で行うことを除いて、すべてを行う必要があります。
ジョシュ・セガールが言ったことと並行して、私はそれについてコメントしてください。私はいくつかの非常に大規模なレガシー システムに取り組んできましたが、それらは私の膝の上に放り出されました。最大の問題は、コードの特定のセクションについて既に学んだことを追跡することであることがわかりました。「To Do」メモを含め、メモを書き始めたら、すでに理解していたことを再理解するのをやめました。次に、それらのコード セグメントがどのように流れ、相互作用するかに集中できます。
パーティーに遅れましたが、関数/メソッドが頻繁に使用または参照される場合、次のことを行う価値があります。
if1 行に配置します。これらは、あなたが探している大規模な見出しの影響を与えないかもしれませんが、特にコードが単体テストできない場合、リスクは低くなります。