コードが「レガシー」になるのはいつですか？
私たちはすべてそれを実行し、いくつかのコード（多くの場合、継承したもの）を「レガシー」としてラベル付けしましたか？しかし、それはまだ本番システムで使用されています-それでそれは本当にレガシーですか？そして、何がそれをレガシーにしますか？完全に機能するコードのこの不当なラベル付けを避けなければなりません。ラベリングが純粋な便利さである場合、新しいものを押し通して、上層部の管理を素敵で幸せに保つことができますか？
回答のまとめ
答えを見ると、4つの一般的なテーマがあります。内訳を見ると、次のようになります。
- 配信されたコード：6
- 死んだシステム：2.5
- 単体テストなし：2
- 開発者がいない：1.5
私はどちらかと言えば Wikipediaの要約 自分自身：
レガシーシステムは古い方法、テクノロジー、コンピューターシステム、またはアプリケーションプログラムであり、新しいテクノロジーやより効率的なタスク実行方法が利用可能になったとしても、通常はユーザーのニーズに応じて機能するため、引き続き使用されます。
他の人々が答えで述べていることの多くはreasonsコードが「レガシー」になる理由です。しかし本質的な質問自体はこれです：
しかし、それはまだ本番システムで使用されています-それでそれは本当にレガシーですか？そして、何がそれをレガシーにしますか？
それがまだ本番環境で使用されているという事実が、まさにそれをレガシーにしています。コードが適切に機能しない場合、または本番環境で使用されなくなった場合、そのコードはそれぞれ「破損」または「廃止」されます。 レガシーは、まだ使用されており、正常に動作することを意味しますが、一般的に使用されなくなった設計または手法が組み込まれています。
（a）アップグレードまたは更新したいが、できない（b）まだアップグレードの最中であるコードまたはシステムは、レガシーシステムです。これは refactoring または一般的なコードのクリーンアップを意味するのではなく、significant設計への変更を意味します。おそらく、新しいフレームワークまたは新しいプラットフォームを使用します。
システムまたはコードがなるレガシーになる理由はいくつかあります。
定期的なメンテナンスまたは software rot の欠如。アプリケーションが定期的に保守されていない場合、ソフトウェアの世界の大きな変化に対応できないことは明らかです。これは単純な無視によるものか、ビジネスの優先順位または予算の制約に基づく意図的な選択である可能性があります。
テストの欠如。 別の答え テストでカバーされないコードがレガシーコードであるという、人気のある作者の双曲線の主張を参照します。これは実際には正確な定義ではありませんが、is考えられる根本的な原因です。良いテスト（自動または手動）がないと、開発者は何かを壊すことを心配し、上記の「ソフトウェアの腐敗」を引き起こすため、大きな変更を行うことを臆病になり恐れます。
大規模なオープンソースライブラリまたはフレームワークを使用するプロジェクトでは特に見過ごされがちな見過ごされがちな要因であるRev-locking（商用ツールでも発生することは確認していますが）。多くの場合、フレームワーク/ライブラリに対して大幅なカスタマイズが行われ、アップグレードが非常に困難または高額になります。したがって、システムは古い（おそらくサポートされなくなった）プラットフォームで実行されるため、レガシーになります。
ソースコードは使用できなくなりました。つまり、システムは追加のみが可能で、変更はできません。アップグレードするためにこれらのシステムを書き直す必要があるため、段階的/反復的に改訂するのではなく、多くの企業が気になりません。
コードベースの更新を遅くしたり停止したりすると、そのコードベースがレガシーになる可能性があります。
現在、別の、明言されていないが暗黙の質問は、レガシーコードの何が問題になっているのですか？これはしばしば軽蔑的な用語として使用されるため、質問：
完全に機能するコードのこの不当なラベル付けを避けるべきでしょうか？
そして答えはノーです、私たちはすべきではありません。ラベル付けisが保証されており、用語自体が機能するコードを意味することは明らかです。重要なのはthat機能ではなく、-how機能していることです。
場合によっては、レガシーコードに問題はありません。それは悪い言葉ではありません。従来のコード/システムは悪ではありません。彼らはほんの少しのほこりを集めました-時には少し、時にはたくさん。
Legacyはobsoleteになると、システムがクライアントの（すべての）ニーズに対応できなくなる。 Thatラベルは注意が必要なラベルです。それ以外の場合、それは単にコスト/利益の方程式です。アップグレードのコストがそのメリットのコスト（将来のメンテナンスコストの低下を含む）よりも低い場合はアップグレードし、それ以外の場合はそのままにします。 「税務調査」のために通常予約するのと同じ調子で「レガシー」という言葉を吐き出す必要はありません。完全に問題のない状況です。
通常は、言語で記述されているか、通常は新規開発を行わないシステムに基づいていることを意味します。
たとえば、ほとんどの場所では、Cobolで新しいプログラムを作成していません。ただし、彼らのビジネスの大部分は、Cobolで記述されたアプリで実行される可能性があります。したがって、これらのアプリは「レガシー」というラベルが付けられます。
レガシーコードは通常、何らかの方法で孤立します。リード開発者、それを理解した唯一の男はバスに襲われ、彼のノートは彼の母国語であるウクライナの方言で書かれました。または、代わりに Visual Basic 6. で記述されたもの。
私はいつもレガシーコードに取り組んでいます。特徴は次のとおりです。
- 多大な努力なしでは拡張できません
- 新しいハードウェアに簡単に移行できない
- 簡単に置き換えるにはビジネスにとって非常に重要です
これらの特性がない場合は、おそらくレガシーではありません。前任者の Perl スクリプトが気に入らなければ、私は同情しますが、それはレガシーではないと思います。私は最近、廃止された Sybase データベースに組み込まれた15年前のPerlスクリプトを近代化しました。それは私たちの神のような恐ろしい [〜＃〜] cobol [〜＃〜] 会計システムに少しでも変更を加えることと比較すると、簡単なことでした。
Michael Feathersは、彼の著書効果的なレガシーコードの使用で、レガシーコードを単体テストでカバーされていないコードとして定義しています。それは私が同意する1つの定義です。また、レガシーコードは古いものでありながら、まだ使用可能です。
技術的には、レガシーとは、すぐに記述できるコードです。したがって、本番環境に入るとすぐに、それはレガシーです。そこにはすでに価値があるので、それを捨てることはできません...あなたはそれに対処しなければなりません。
それは「あなたの時間の前」ですが、「まだあなたの頭痛」です。
レガシーコードとは、コードベースに残るコードのことです。そうしないと、多くのことが機能しなくなります。つまり、下位互換性があることが唯一の理由です。
変更するか破棄することもできますが、それに依存しているすべてのコード（それに応じて適応できないコードである可能性があります）を壊すため、変更することはできません。したがって、それを保持する必要があります（場合によっては維持することもできます）が、すべての新しいコードがそれに対して作成されないようにする必要があります。
例は、ライブラリのAPIの廃止されたメソッドです。彼らはまだそこにいるので、ライブラリを更新した誰でも彼のプロジェクトをビルドできますが、それらは非推奨としてマークされており、コンパイラは警告を与えるはずです。
別の例は、Microsoftが完全に廃止予定のOSのバージョン用に作成されたプログラムを実行するために行う奇妙なトリックです。この存在の頂点：
私は最初にヒットゲームSimCityの開発者の1人からこれについて聞いた、彼のアプリケーションに重大なバグがあることを私に言った：それはそれを解放した直後にメモリを使用しました。解放されたメモリが、実行中の別のアプリケーションによってすぐに奪われる可能性があるWindowsでは動作しません。 Windowsチームのテスターは、人気のあるさまざまなアプリケーションをテストし、正常に機能することを確認するためにテストしましたが、SimCityはクラッシュし続けました。彼らはこれをWindows開発者に報告し、SimCityを逆アセンブルし、デバッガーでそれを実行し、バグを見つけ、SimCityが実行されているかどうかをチェックする特別なコードを追加し、実行された場合は、メモリアロケーターを特別なモードで実行しました。解放後もメモリを使用できます。
-Joel on Software
レガシーは継承を伴います。レガシーコードは、単に過去から継承したコードです。以前に自分で作成した場合でも、これはレガシーコードです。
他のすべての考慮事項は、基本的には、現在のプロジェクト用に特別に記述しなかったという事実から派生しています。それ自体が必ずしも悪いことではありません。
私の意見では、レガシーコードと見なされるものは複数のものに依存し、タグ「レガシー」はおそらく組織固有のものであると考えています。
それが実行されているハードウェア/ OSが古く、ベンダーによって中止されている場合-ストライク1。
何らかの理由で、それを書き直すよりも修正しようとするより多くの作業である場合
- 元の開発者がいなくなりました
- プログラムがひどく書かれている
- 新しいプラットフォームでよりよく行うことができ、会社にとってはそれだけの価値があります
そうするには
- 元のソースが利用できなくなっているか、欠落している部分がある
ストライク2。
複数の組織を1つに統合する-ストライク3-一方はおそらくレガシーとしてタグ付けされます。
サードパーティのアプリケーションやサービスとして販売されているより良い、より安価な代替品はありますか-ストライク4。
組織は病院や学区のようなものであり、日常業務に関して新しいテクノロジーよりも一貫性が重視されていますか？アプリケーションがレガシーと見なされるまでには、営利/競争組織の同じアプリケーションと比べて時間がかかります。
会社が小規模な開発会社であり、顧客が必要とすることを実行するためにアプリケーションを拡張/サポートし続ける場合、それはレガシーコード、または単に「古い」コードと見なされます。私はMc2Okという名前の会社を知っています。彼らはWindows 3.1であると思われるソフトウェアを開発し、今も引き継いでいます。 Windows 3.1のルックアンドフィールは非常に多くありますが、Webインターフェイスも追加されています。それは二人の開発会社（私の推測）であり、彼らがその作業をやめたとき、それはレガシーと見なされ、それを使用した場合は1、2年後に移行する時間になると思います。しかし、それはさらに10年以上かかる可能性があります。
時々、管理が変更されると、それは多くの細流効果を持つ波で変化する可能性があります...新しい管理の影響力に応じて、他の方法ではうまくいくかもしれない多くのアプリケーションをレガシーにすることができます。
各組織は、「レガシーコード」が何を意味するかを定義する必要があると思います。私はThe Sunday Timesクラシファイドを毎週調べて、組織が探していたものを確認していました。それは、もはや関係のないもの（つまり、レガシー）の私のバロメーターでした。さて、Sunday Timesはもはや関係ありません:-)そして、COBOLがレガシーであることを一般化できます ASP Classic はレガシーですなど...しかし、アプリケーションがレガシーと見なされるタイミングを各組織が決定する必要があると思います。
彼はそれを壊すかもしれないので、それを変更することを恐れるとき、コードはレガシーです。そのコードへの変更によってシステム全体がこねられる可能性がある場合、それはさらに苦痛です。
これが、私がマイケルフェザーズの定義にも同意する理由です。優れた単体テストを持つコードは、恐れることなく変更できます。
また、レガシーコードは、その古さには関係がないと思います。最初からレガシーコードを書くことができます。