多くの開発者がコードを「レガシー」と呼んでいると聞いています。ほとんどの場合、プロジェクトに携わっていない人が書いたコードです。コード、レガシー コードを作るのは何ですか?
「先祖、前任者、または過去から受け継がれたもの」http://www.thefreedictionary.com/legacyに応じて更新します。明らかに、あなたは何か他のことを知りたがっていました。質問を明確にするか、拡大していただけますか？S.ロット
レガシー コードが使用できなくなったり、作業が困難になったりする症状を探しています。捨てたほうがいいのはいつ？コードはもっと頻繁に捨てるべきであり、車輪の再発明は開発の貴重な部分であるというのが私の意見です。車輪の再発明をしないという学術的な理想は素晴らしいものですが、あまり実用的ではありません。
一方で、保持する価値のあるレガシー コードも明らかにあります。
ハードウェア、ソフトウェア、API、言語、テクノロジー、または機能がサポートされなくなった、または置き換えられたものを使用することにより、通常、そのコードを置き換える可能性はほとんどまたはまったくなく、代わりにそれを使用するか、システムが死ぬまで使用します。
コード、レガシー コードを作るのは何ですか?
単純な遺産と同様に、作成者が死亡または行方不明になった場合、あなたは相続人として彼のコードのすべてまたは一部を取得します。
あなたは涙を流し、このすべてのゴミをどうするかを理解しようとします.
Michael Feathers は、彼の著書「レガシー コードを効果的に使用する」で興味深い定義をしています。彼によると、レガシー コードは自動テストのないコードです。
これは非常に一般的な (そしてしばしば乱用される用語) ですが、次のいずれかがアプリのレガシーと呼ぶ正当な理由になります。
コードベースは、元の製品のメーカーによって完全にサポートされていない言語/プラットフォームに基づいています (多くの場合、メーカーは廃業したと言われています)。
(本当に 1a) それが構築されているコード ベースまたはプラットフォームが非常に古いため、システムの資格のあるまたは経験豊富な開発者を獲得することは難しく、費用がかかります。
アプリケーションは、もはや積極的に成長しておらず、変更が非常にまれなビジネスの側面をサポートします。通常、何かまったく予期しない変更が発生した場合 (標準的な例は Y2K 問題)、または何らかの規制や外部からの圧力によって修正されます。それ。どちらの理由も差し迫ったものであり、通常は避けられませんが、プロジェクトで大きな進展が見られないため、これに対処するために割り当てられた人々はシステムに慣れていない可能性があります (そして、システムの動作と複雑さが蓄積されています)。このような場合、これは多くの場合、プロジェクトに関連するリスクの認識および計画を増加させる理由になります。
システムが別のシステムに交換されている/または交換中です。そのため、システムは当初の意図よりもはるかに少ない用途で使用されるか、履歴データを表示する手段としてのみ使用される可能性があります。
レガシーとは一般に、もはや開発されていないコードを指します。つまり、それを使用する場合は、元の条件で使用する必要があります。今日の世界がどのように見えるかをサポートするために単に編集することはできません。たとえば、レガシー コードは、現在存在しない、またはサポートされなくなったハードウェアで実行する必要があります。
優れた『Working Effectively with Legacy Code』の著者である Michael Feathers によると、レガシー コードはテストのないコードです。このコードが変更されたときに何が壊れるかを知る方法がない場合。
レガシー コードと非レガシー コードを区別する主な点は、テスト、またはむしろテストの欠如です。ちょっとした思考実験でこれを理解することができます: コードベースを修正するのはどれほど簡単でしょうか? もし間違いを犯したときに教えてくれるとしたら? それはかなり簡単でしょうね。大規模なコード ベースに変更を加える際の恐怖のほとんどは、微妙なバグが入り込むことへの恐怖です。不注意で物事を変えることへの恐れ。テストを使えば、何もせずに物事を改善できます。私にとって、この違いは非常に重要で、他のどんな違いよりも圧倒されます。テストを使用すると、物事を改善できます。それらがなければ、状況が良くなっているのか悪くなっているのかわかりません。
以前、同僚から、レガシー コードとは自分で書いていないコードのことだと言われました。
間違いなく、何らかの理由で (通常はクールでもファッショナブルでもなく、機能するため) もはや好まないコードに対する軽蔑的な用語です。
TDD 旅団は、テストのないコードはすべてレガシー コードであると示唆する場合があります。
レガシ コードとは、サポートされなくなった、または製造されたオペレーティング システムまたはその他のコンピューター テクノロジに関連するソース コードです。
http://en.wikipedia.org/wiki/Legacy_code
"レガシー コードは、もはやサポートされていない、または製造されていないものに関連するソース コードです"
サポート (またはドキュメント) が欠落しているコード。それは：
私にとってレガシー コードとは、何らかのパラダイム シフトの前に書かれたコードです。それはまだ非常に使用されているかもしれませんが、それを一直線に並べるためにリファクタリング中です。
たとえば、そうでなければ OO システムにぶら下がっている古い手続き型コード。
レガシー コードを保存することは、学術的な理想というよりも、機能するコードを保存することです。多くの保守的な企業の状況では、それを捨ててゼロからやり直すよりも実用的であると考えられます。あなたが知っている悪魔の方がいい...
コード (またはその他のもの) は、より新しい/より優れたものに置き換えられると「レガシー」になりますが、それにもかかわらず、「実際に」使用され、生き続けています。
次の条件のいずれかまたはすべてが当てはまる場合、コードは「レガシー」と見なされます。
ここでの他の意見のいくつかとは異なり、単体テストなしで適切に機能する最新のアプリケーションをたくさん見てきました。ユニットテストはまだ誰もが理解しているわけではありません。おそらく今から10年後、次世代のプログラマーは現在のアプリケーションを見て、オブジェクト指向ではないアプリケーションをレガシーと見なすのと同じように、単体テストを含まない「レガシー」と見なします。
従来のコードベースに加える必要のある変更がほとんどない場合は、そのままにしてフローを続行することをお勧めします。アプリケーションで機能の大幅な変更、GUIのオーバーホールが必要な場合、および/またはプログラミング言語を知っている人が見つからない場合は、捨ててやり直すときが来ました。ただし、警告があります。最初から書き直すのは非常に時間がかかる可能性があり、すべての機能を複製したかどうかを知るのは困難です。おそらく、レガシーアプリケーションと新しいアプリケーション用にテストケースと単体テストを作成することをお勧めします。
正直なところ、レガシーコードは、もはや「クール」ではない他のソフトウェア構成のコード、フレームワーク、APIです。たとえば、COBOL は全会一致でレガシーと見なされますが、APL はそうではありません。現在、COBOL がレガシーであり、APL と見なされているのは、APL の約 100 万倍のインストール ベースがあるためではないと主張することもできます。ただし、APL コードに取り組む必要があると言った場合、その返事は「ああ、そのレガシーなもの」ではなく、「なんてこった、次の世紀には何もしないと思うよ」と答えるでしょう。違いがわかりますか?
レガシーコードは1か月以上前に書かれたものです:-)
多くの場合、トレンディなスクリプト言語 du jour で書かれていないコードです。半分冗談です。