コードはいつ「レガシー」ですか？[閉まっている]

すべて完了しました。一部のコード（多くの場合、継承したもの）を「レガシー」とラベル付けしましたか？しかし、それはまだ実稼働システムで使用されています-それは本当にレガシーですか？そして、何がレガシーなのでしょうか？完全に機能するコードのこの不当なラベル付けを避けるべきでしょうか。ラベリングは純粋な利便性であり、新しいものを押し通して上層部の経営陣を満足させることができますか？

回答の要約

答えを見ると、4つの一般的なテーマがあります。内訳は次のとおりです。

1. 配信されたコード：6
2. デッドシステム：2.5
3. 単体テストなし：2
4. 開発者がいない：1.5

私はウィキペディアの要約にかなり偏っています：

レガシーシステムとは、新しいテクノロジーやより効率的なタスク実行方法が利用できるようになったとしても、通常はユーザーのニーズに応じて機能するためです。

他の人がその答えに記述しているものがたくさんあるの理由コードが「レガシー」になり、なぜ。しかし、本質的な質問自体は次のとおりです。

しかし、それはまだ実稼働システムで使用されています-それは本当にレガシーですか？そして、何がレガシーなのでしょうか？

それがまだ生産で使用されているという事実は、まさにそれをレガシーにするものです。コードが適切に機能しない場合、または本番環境で使用されなくなった場合、そのコードはそれぞれ「破損」または「廃止」されます。 レガシーとは、まだ使用されていて正常に動作することを意味しますが、もはや一般的に使用されていない設計や技術を取り入れています。

（a）アップグレード/更新したいができない、または（b）まだアップグレード中のコードまたはシステムは、レガシーシステムです。これは、リファクタリングや一般的なコードのクリーンアップを意味するものではなく、新しいフレームワークや新しいプラットフォームを使用する可能性のある、設計の大幅な変更を意味します。

システムまたはコードがレガシーになる理由はいくつかあります。

• 定期的なメンテナンスやソフトウェアの腐敗の欠如。明らかに、アプリケーションが定期的に保守されていないと、ソフトウェアの世界の大きな変化に対応できません。これは、単純な怠慢によるものかもしれませんし、ビジネスの優先順位や予算の制約に基づいた意図的な選択かもしれません。

• テストの欠如。別の答えは、テストでカバーされないコードがレガシーコードであるという人気著者の双曲線的主張を参照しています。これは実際には正確な定義ではありませんが、根本的な原因である可能性があります。優れたテスト（自動または手動）がなければ、開発者は何かを壊すことを心配するため、大きな変更を行うことをti病に、恐れます。

• Rev-lockingは、大規模なオープンソースのライブラリまたはフレームワークを使用するプロジェクトで特に潜行性のある見過ごされがちな要素です（商用ツールでも同様です）。多くの場合、フレームワーク/ライブラリに大規模なカスタマイズが行われ、アップグレードが非常に困難または高価になります。したがって、システムは古い（およびサポートされなくなった）プラットフォームで実行されるため、レガシーになります。

• ソースコードは使用できなくなりました。つまり、システムを追加するだけで、変更することはできません。漸進的/反復的に修正するのではなく、これらのシステムをアップグレードするために書き直す必要があるため、多くの企業は気にしません。

コードベースの更新を遅くしたり停止したりすると、そのコードベースがレガシーになる可能性があります。

さて、個別の、明示されていないが暗示された質問は、レガシーコードの何が問題なのですか？ 多くの場合、軽as的な用語として使用されるため、次の質問があります。

完全に機能するコードのこの不当なラベル付けを避けるべきでしょうか？

そして答えはノーです、すべきではありません。ラベリングが保証されており、用語自体が機能するコードを明確に暗示しています。ポイントは、それが機能しているということではなく、それがどのように機能しているのかということです。

場合によっては、レガシーコードに問題はありません。それは悪い言葉ではありません。レガシーコード/システムは悪ではありません。彼らはちょうどいくつかの塵を集めました-時々少し、時々たくさん。

システムがクライアントのニーズ（すべて）を処理できなくなると、レガシーは廃止されます。 このラベルは、注意する必要があるものです。それ以外の場合、それは単に費用/便益の方程式です。アップグレードのコストがそのメリットのコスト（将来の保守コストの削減を含む）よりも低い場合は、アップグレードします。それ以外の場合はそのままにしておきます。「税務監査」のために通常予約しているのと同じトーンで「レガシー」という言葉を吐き出す必要はありません。入るのはまったく問題ない状況です。

通常、それは言語で書かれているか、通常は新しい開発を行わないシステムに基づいていることを意味します。

たとえば、ほとんどの場所はCobolで新しいプログラムを作成しません。ただし、ビジネスの大部分はCobolで作成されたアプリで実行できます。したがって、これらのアプリには「レガシー」というラベルが付いています。

レガシーは、あなたがしたい任意のコード意味ではなくて仕事よりも、置き換えが。ほとんどの既存のコードに対するほとんどのプログラマーの態度を考えると、これには通常、現在アクティブに書いているもの（そして、凍結したデザインにコードを書かなければならない大規模なプロジェクト、瞬間も含めることができます）。

1. 「むしろ」という強調は、レガシーコードは、そうではなくても、それを使って作業をしていることを意味することを伝えることを目的としています。しかし、強調が十分であったかどうかはわかりません。その理由はさまざまです。一部のものは、大きすぎて複雑すぎて置き換えることができません。その他は、他のシステムへのインターフェースです。さらには、政治や人格に左右されます（たとえば、コードは恐ろしいですが、ブースの可愛い人はすごかったです）。
2. 私が十分に強調していなかった別の点は、コード品質が要因になる可能性があるが、それが唯一の要因であるということはめったにないことです。
3. 唯一の決定要因として単体テストを推進している人々は、妻がブロックを落としたイヤリングを街灯の下で見ているようなものだと思います。光は良いかもしれませんが、あなたはまだ間違った場所を見ています。Kool-Aidを飲む前に考えてください。
4. （3への帰結）私には、一部の人々は、彼らが実際にどのようであるかよりも、彼らが物事をどのように望んでいるかについてもっと話しているように思えます。場合ジョンConways「ライフゲームのためのApple IIcのPlusはレガシーではありません、それはそれは地上から再実装するのは簡単だということを十分に小さくてシンプルだから、それはです。これまでに書かれた最も完璧な単体テストは、単一のイオタを変えません。

最後の点は、私がしばしば真実だと思う他の2つの点につながります。

第1に、コードは、本来そうあるべきではない場合でも、しばしばレガシーとして保持されます。上級管理者は一般に、システムの再実装には初期実装と同じかそれ以上のコストがかかると想定していますが、これはめったにありません。

第二に、ユニットテストは両刃の剣です。それらは、実装のローカライズされた変更が本当に重要なことだと考えることをあまりにも簡単にします。大規模なシステムで大幅な改善を行うには、多くの（ほとんどではないが）単体テストが無関係になるように、全体的な設計を頻繁に（通常？）変更する必要があります。残念ながら、単体テストの存在とそれらがもたらす態度により、本当に必要な変更を無視するのは非常に簡単になります。

おそらくその一例が役立ちます。プログラムに、優れたユニットテストを備えたUIライブラリと、そのライブラリを使用するいくつかのプログラムがあると仮定しましょう。上級管理職の誰かが、「Web対応」が重要であると確信するようになります（そして、議論のために、この場合、彼は実際にそれについて正しいと仮定しましょう）。慎重なレビューの後、中間管理者は、元の入力検証をすべて保持しながら、現在の単体テストで、ローカルオペレーティングシステムのウィンドウ機能を介して表示されるユーザーインターフェイスからHTML / CSS / AJAXを介してリモートで表示されるように変更できることを確認しました。

すごいですね。単体テストの有用性を示しています。UI全体の実装全体を交換しましたが、ルックアンドフィールと機能がほぼ一貫したままであり、すべてのユーザー入力が検証されてデータの整合性が確保されています。単体テストで時間を節約できました！

か否か！素晴らしく、非常に柔軟で、慎重にユニットテストされたUIライブラリは、ユーザーがいる市場のこのプログラムにとって、WebベースのUIはまったく間違った作業であるという事実に関係するすべての人を盲目にさせました。本当に必要なのは、RESTfulインターフェイスを備えたWebサービスであり、独自の UIはまったくありません。

さて、ユニットテストがそれ自体で、人々が自分の市場を理解したり、それが本当に必要であることを認識したりする能力を排除するわけではないことは確かです。同時に、ハンマーと釘についての古い線は、心に事実上飛躍します。あなたがハンマーを持っているだけでなく、このハンマーで多くの経験を持ち、多くの異なる状況で非常にうまく機能する本当に高品質のハンマーであることを知っているとき、それはさらに悪化する可能性があります。非常に多くの状況で非常に多くのことが得意であるという事実は、それが手元の仕事にとって完全に間違ったツールであるときを認識することをさらに困難にします。

通常、レガシーコードは何らかの形で孤立しています。リード開発者、それを理解した唯一の男がバスに襲われ、彼のメモは彼の母国語であるウクライナ語で書かれました。または、代わりに、Visual Basic 6.0で書かれたもの。

私はいつもレガシーコードに取り組んでいます。特徴は次のとおりです。

• 多大な努力なしには拡張できません
• 新しいハードウェアに簡単に移行できない
• 簡単に交換するにはビジネス上非常に重要です

それらの特性がない場合、おそらくレガシーではありません。前任者のPerlスクリプトが気に入らない場合は同情しますが、レガシーとは思いません。私は最近、時代遅れのSybaseデータベースと結婚していた15歳のPerlスクリプトを近代化しました。これは、私たちのひどいCOBOLアカウンティングシステムにわずかな変更を加えた場合と比べても簡単でした。

Michael Feathersは、著書「Legacy Codeを効果的に使用する」で、レガシーコードを単体テストでカバーされないコードとして定義しています。それは一つの定義であり、私はそれに同意します。また、レガシーコードは古いものの、まだ使用可能であると考えています。

技術的には、レガシーとは、すぐに作成できるコードです。そのため、本番環境ではすぐにレガシーになります。そこにはすでに価値があるので、ただ捨てることはできません...それに対処しなければなりません。

それは「あなたの時間の前」ですが、「頭痛の種」です。

レガシーコードは、コードベースにのみ残っているコードです。そうしないと、多くのことが機能しなくなるからです。言い換えれば、存在する唯一の理由は後方互換性です。

むしろ変更するか、破棄することもできますが、依存しているすべてのコードを壊すため、変更することはできません（それに応じて適応できないコードである可能性があります）。したがって、それを保持する必要があります（場合によっては維持することもあります）が、すべての新しいコードがそれに対して書き込まれないようにしたいと考えています。

例は、ライブラリのAPIの非推奨のメソッドです。それらはまだ存在しているため、ライブラリを更新する人がプロジェクトをビルドできる場合でも、非推奨としてマークされ、コンパイラから警告が表示されます。

もう1つの例は、完全に非推奨になったOSのバージョン用に作成されたプログラムを実行するためにMicrosoftが行うすべての奇妙なトリックです。この存在の頂点：

ヒットゲームSimCityの開発者の1人からこのことを最初に聞きました。彼のアプリケーションには重大なバグがあると言われました。解放直後にメモリを使用しました。解放されたメモリが別の実行中のアプリケーションによってすぐに奪われる可能性があるWindowsでは動作しません。Windowsチームのテスターは、人気のあるさまざまなアプリケーションを試し、正常に動作することを確認するためにテストしていましたが、SimCityはクラッシュし続けました。彼らはこれをWindows開発者に報告しました。Windows開発者はSimCityを分解し、デバッガーでステップスルーし、バグを見つけ、SimCityが実行中かどうかを確認する特別なコードを追加しました。解放後もメモリを使用できます。
-ソフトウェアに関するジョエル

レガシーには継承が伴います。レガシーコードは、単に過去から継承したコードです。以前に自分で作成したコードでも、レガシーコードです。

他のすべての考慮事項は、基本的に、現在のプロジェクト専用に作成しなかったという事実に基づいています。それ自体が必ずしも悪いことではありません。

私の意見では、レガシーコードと考えられるものは複数のものに依存しており、「レガシー」タグはおそらく組織固有のものであると考えています。

実行するハードウェア/ OSが古く、ベンダーによって廃止されている場合-ストライク1。

何らかの理由で、書き換えるよりも修正しようとする方が手間がかかる場合

• 元の開発者はいなくなりました
• プログラムがひどく書かれている
• それは新しいプラットフォームでより良くすることができ、それでも会社にとって価値がある

そうするために

• 元のソースが使用できなくなっているか、ピースが欠落している

ストライク2。

複数の組織を1つに統合すると（ストライク3）、一方がおそらくレガシーとしてタグ付けされます。

サードパーティのアプリケーションやサービスとして販売されている、より良い、より安価な代替品があります-ストライク4。

組織は、日々の業務に関して、新しい技術よりも一貫性が重視される病院や学区のようなものですか？商用/競争力のある組織の同じアプリケーションと比較して、アプリケーションがレガシーと見なされるまでに時間がかかります。

顧客が必要とすることを行うためにアプリケーションを強化/サポートし続ける小規模な開発会社である場合、それはレガシーコードと見なされますか、それとも単に「古い」コードと見なされますか。Mc2Okという会社を知っています。彼らはWindows 3.1のように見えるソフトウェアを開発し、それを続けています。まだWindows 3.1のルックアンドフィールを備えていますが、Webインターフェイスも追加されています。これは2人の開発会社です（私の推測では）、彼らが作業をやめるとレガシーと見なされ、使用する場合は1〜2年後に移行する時間になると思います。しかし、それはさらに10年以上になる可能性があります。

時々、管理が変更されると、多くの細流効果を持つ波のように変化する可能性があります...新しい管理の影響力に応じて、多くのアプリケーションをレガシーにすることができます。

各組織は、「レガシーコード」の意味を定義する必要があると思います。私は毎週The Sunday Timesの分類を調べて、組織が探しているものを確認していました。以前は、関連性がなくなった（つまり、レガシー）のバロメーターでした。さて、The Sunday Timesはもはや関係ありません:-)そして、COBOLがレガシー、ASP Classicがレガシーなどを一般化することができます。しかし、各組織がアプリケーションをレガシーと見なすタイミングを決定する必要があると思います。

コードが壊れる可能性があるため、コードを変更することを恐れている場合、コードはレガシーです。そのコードの変更によってシステム全体が混ざり合う可能性がある場合は、さらに苦痛です。

これが、マイケルフェザーズの定義にも同意する理由です。優れた単体テストを持つコードは、大胆に変更できます。

また、レガシーコードはそれがどれほど古いかには関係ないと思います。最初からレガシーコードを書くことができます。