全体として：レガシーシステムをどのように維持しますか？[閉まっている]

ニューヨーク-超高層ビルを震わせた爆発により、83年前の蒸気パイプは、ニューヨークや他の米国の都市の下にある何マイルものチューブ、ワイヤー、鉄が古くなり、危険なほど不安定になる可能性があるという強力なメッセージを送りました。

マンハッタンのバースト蒸気パイプに関する2007年7月のストーリー

ソフトウェアの腐敗と技術的負債について聞いたことがあります。

そして、私たちは次のような人から聞いたことがあります：

• 「ボブおじさん」マーティン-「混乱させることの結果」について私たちに警告した人。
• Michael C. Feathers- 「レガシーコードで効果的に作業する」ためのガイダンスをくれた人。

したがって、ソフトウェアエンジニアリングコミュニティはこれらの問題を認識しています。

しかし、私たちの社会全体は、これらの問題が稼働中のシステムやアプリケーションをどのように悩ませるのか理解していないように感じます。

Steve McConnellが指摘するように：

...金銭的負債とは異なり、技術的負債ははるかに目立たないため、人々はそれを無視する方が簡単です。

もしこれが真実であり、そうだと思うなら、政府や企業は手遅れになるまでハッカーに対する定期的な保守と強化を延期するのではないかと恐れています。[NYCや蒸気パイプによく似ています。]

私の質問：

• NYCや蒸気パイプに相当するソフトウェアを回避する方法はありますか？

レガシーシステムのメンテナンスに関連する重要な問題は、a）それらのシステムの速度に対応しており、b）システムを維持し続ける意思のある人々が不足していることです。

私は最近、若いプログラマーがメインフレームにまったく興味があるかどうかについて、同様の方針に沿って質問をしました。コンセンサスはノーに傾いた。

レガシーシステムの維持は、キャリアの自殺と見なされます。慣性が支配している多くの企業では、これらのシステムを維持するためのトレーニングスタッフへの投資はほとんどなく、人事側の単一障害点につながります。私が知っている多くの人々は、同様のシステムで仕事をしている人たちは、システムの長期的な将来を見ることはなく、キャリアの損失しか見ないため、ルートを探しています。

一部の業界では、データ保守規制がレガシーシステムが合理的に監視されることを保証する重要な要素になる場合があります。これは特に金融業界の問題だと思います。これらの規制は、私が知る限り、一般的に時間制限があります。

しかし、実際には、何が起こるかと思います：

グラフには、レガシーシステムの短所を回避できる最新のシステムに切り替わるコストが、レガシーシステムが安価であるため、レガシーシステムを維持するコストを下回るポイントがあります。

IBMは現在、多くのメインフレームを販売しています。彼らは、大型マシンが若い専門家の群れをシャットアウトしないように非常に懸命に働いています。しかし、私はこの段階では十分ではないと思います。二酸化炭素排出量と実際の処理能力の点で、いくつかのUSPがあります。

ただし、Linuxを実行できるためにIBMメインフレームを購入する人、電気代が安く、効率が高い人には、その世界に精通しているため、サーバーファームを選択する人がさらに数人います。さらに多くのプログラマーもいます。

最終的には、関係する業界に大きく依存します。私は長年にわたってメインフレームに非常に依存してきた特定の業界で働いており、それらはまだ広く使用されています。しかし、大規模企業のスキルを統合できるホスト型ソリューションがより一般的になりつつあります。これにより、個々の企業が直面する問題点がいくつか解消されます。その業界に固有の問題のため。

要約すると、私が言っていることは、概して、メンテナンスと移行の経済的ポイントが移行に有利になるとすぐに、レガシーシステムからの移行に向かうということです。ただし、多くの人にはほとんど目立たないでしょう。なぜなら、それは新しくてファンキーではなく、次の大きなもののようにあまり一般的な顔をしていないからです。その移行は、サービスプロバイダーまたは新しいテクノロジー（特に、サービスプロバイダーが直接影響を受けるもの）に対するものです。

私の経験-特にネットワークでの経験-では、レガシーシステムへの依存を取り除く動きがあります。

ほとんどの企業はすでに技術的な負債を知らず、文字通り彼らの周りで崩壊し、破産するまでそれが悪いことだとさえ気付かない（その点に到達した場合）。私は実際に見ましたそれが起こり、それはきれいではありませんでした。さらに悪化したのは、増え続ける技術的負債とそれを修正しなければならないことを事業主に繰り返し認識させようとしたという事実であり、修正に必要な時間とリソースを費やしたくないために拒否されるたびにそれ。最終結果は、10年以上後にシステムが壊滅的に（私が去った後）失敗し、回復することができず、廃業したのです。問題を完全に無視するよりも問題を修正する必要があります。私はその会社の馬鹿げた愚かさについて何時間も暴言を吐くことができました、そして、私が最も痛かったのは、所有者がいなければ完全に回避できたことでした 他のすべてを完全にカットすることで、簡単にお金を稼ぐだけです。

彼らのシステムがひどく書かれていて、重いリファクタリングが必要かどうかをビジネスに伝えることはめったに難しいことではありません（それが悪いので通常そうである完全な書き換えではありません）。ほとんどの時間、彼らはちょうどあなたがそれが新機能を変更を加える、または追加するのは難しいと彼らに警告していても、あなたを撃墜よ（、私はちょうど杭の上よりがらくたを重ねない、正しい方法を意味する）、あるいは検討します現在の状態のシステムに問題があるため、ビジネスに悪影響を及ぼします。

正直に言って、それは負けの戦いであり、戦う価値のない戦いであるという結論に達しました。技術的な負債について知るのに十分賢い人々は、それについて二度話す必要はなく、最初から危険に気づいており、他の誰もがとにかく手遅れになるまで、どんな種類の理由や警告にも耳を傾けません。最良の（そしてもちろん、最も非現実的な）オプションは、自然選択を開始し、無知な人々を絶滅させ、知的なものだけを残すことです。私が過去に個人的に試したことはすべて完全に無視されているか、会社の目で価値を下げている（「苦情を申し立てている」ため）、さらには私は「何が」を修正することに「集中しすぎた」ので、私の終了に至りました 壊れており、他の誰もそれが壊れているのを見る適切な精神状態を持っていませんでした。

ニューヨークや他の米国の都市の下にある何マイルものチューブ、ワイヤー、鉄は老朽化し、危険なほど不安定になる可能性があります。

逸話については、16-17世紀にパリでも同じ議論がなされました。その下には非常に多くの穴とトンネルが掘られていたので（地域の地質による自然の穴に加えて）、時々建物が崩れてしまいました。

街区全体が地面に倒れるまでに、不要な穴やトンネルを砂利や骨で埋めるように指示が出されていました（墓地の混雑問題もありました）。コンクリートが発明されるまで、都市はそのように生き残った。

私のここでのポイントは、多くの組織が土壇場でソフトウェアメンテナンスを行う傾向があることですが、コーダー（土木技術者など）が多くの場合、迅速かつ適切に作業を完了します。

Y2kのバグを乗り切りました。Y2036のバグにより、多くの組織はハードウェアとソフトウェアのアップグレードを余儀なくされます。世界は2012年に終了する可能性があります。しかし、コンピューター科学者は社会学者でも文学批評家でもありません。

ああ、その間sayingにあるように、次のメンテナーがあなたの住んでいる場所を知っている悪質なサイコパスであるかのようにコードを書いてください。

私は忘れてしまいました、私たちは最近、レガシーコードをどう考えていますか？昨年のコード、過去10年のコード、または前世紀のコード

お金は、レガシーシステムのメンテナンスに関する会話を促進します。技術的負債は、システムを変更するためのコストの増加という形をとります。

設計が不十分で、インテリジェントに設計されたシステムで作業しました。興味深いのは、それらを維持するためのコストがそれほど変化しないことです。最大の問題は、現在使用しているアーキテクチャが正しくないことです。これは通常、スケーリングの問題や大きな変更が必要な場合に発生します。コードの主要な領域をシングルスレッドからマルチスレッドに簡単に変換することはできません。

私が経験する最も重要な問題は、使用されている開発言語です。古いシステムは現在あまり人気のない言語で書かれているため、より多くのトレーニングを行うか、より熟練した（高価な）希少なリソースを採用する必要があります。どちらの場合も、プールが小さいため、解決策と同じくらい多くの問題を引き起こす傾向がある熟練した個人を見つけるのに苦労します。

約束された書き換えについては、莫大な投資をしたほとんどのシステムは書き換えを正当化しません。ソフトウェアをどれだけ長く機能させて機能強化できるかは驚くべきことです。ハードウェアの変更（私の会社がサポートしている一部のシステムは、特殊なハードウェアを使用しています）が最大の問題になる傾向があります。多くの場合、拡張機能は、レガシーコードを新機能と統合するメカニズムによってのみ制限されます。

これはすでに大きな問題です。そして、それは変化の兆候を示していません。

60年代および70年代には、あらゆる種類の大規模な機関が、紙の会計処理からコンピューティングシステムの会計処理に移行しました。圧倒的にCOBOLを選択しました。 ほとんどの場合、これらのCOBOLシステムの更新バージョンがまだ使用されています。これに関する統計については、http：//cis.hfcc.edu/faq/cobolを参照してください。

アーノルド・シュワルツェネッガーが数年前に、6か月の開発なしでは20万人の州労働者の賃金を単純に削減できないことを発見したときのように、私たちはしばしばこのことをランダムに思い出させます（http：//www.infoworldを参照してください。 com / d / developer-world / californias-cobol-conundrum-067（検証用）。

切り替えのリスクを考えると、これらのシステムの変更を正当化することは非常に困難です。今まで。それは私の生涯の現実でした。しかし、その事実が私の子供の生涯で変わる理由はないと思います。または彼らの子供の生涯。

自分よりも古いコードを保守している友人がいます。彼女が初めて働いてから30年後に会社に戻ってきた友人がいて、彼女のプログラムは、彼女が覚えてさえいなかった言語で、変更されずにまだ実行されていました！

最後に、両方が発生する可能性のある実話を締めくくります。

1970年代、会社トレーダーにオンライン市場を提供するために設立されました。PDP-11はそれらに適した価格/性能であったため、彼らはそれを選択しました。マシンのパフォーマンスの限界を押し広げていたため、高度に最適化されたPDP-11アセンブリでシステムを記述しました。数年後、PDP-11は販売されなくなりました。しかし、ビジネスは素晴らしく、マシンは長持ちし、中古品の交換は簡単にできました。彼らはプラットフォームを維持しました。その数年後、代替品の入手が難しくなりました。主要なプロジェクトは、取引プラットフォームを置き換えるために行われました。失敗しました。彼らは再び試みた。そしてまた失敗しました。失敗の主な原因は、取引システムがどのように機能するかを誰も知らず、PDP-11アセンブリをこれ以上読み取ることができなかったことです。それから救いが当たった。誰かがLinux上で実行されるPDP-11アセンブラーを作成しました。

したがって、2000年に年間10億ドルの取引が発生した取引は、イーサネット-デクネットブリッジを介してLinuxマシンに行き、高度に最適化されたPDPで記述されたソフトウェアシステムで取引を実行するPDP-11マシンをエミュレートしました。 11アセンブリ。スピードのため。

過去10年間、この会社とは関係がありませんでした。したがって、それらがまだエミュレートされたPDP-11で実行されているかどうかはわかりません。私は、10進数化がマージンを痛めつけていたことを知っているので、移行するためのさらに別の努力がありました。（私はそこから解雇された数人にインタビューし、何が起こったのかを尋ねたので、私は物語を学びました。）しかし、以前の失敗を考えると、私は彼らがそのシステムをうまく置き換えなかったという不思議よりも良いことを与えます。

ユーザーの観点からは非常に純粋な懸念のように聞こえます。腐敗を遅らせるか、改善するためには、問題のソフトウェアがその束縛から解放されている必要があります。パブリッシャーは、ソースコードを無料に設定するか、最後のユーザーが使用を停止するまでソースのメンテナンスとアップグレードを行う必要があります。そうでなければ、ビジネスの世界で同様の腐敗のために彼らが廃業する可能性が非常に高いので、ソフトウェアは腐敗に対して完全に開かれたままになります。

つまり、ソフトウェアの著作権とライセンスの制限の期間は非常に短くする必要があり、その最後に、ソフトウェアとそのコードベースはパブリックドメインに入り、そこにとどまります。したがって、ユーザーがソースをアップグレードし続けること、または誰かがそれを行うように雇うことにより、腐敗を遅延および/または回避することを可能にします。

または、フリーソフトウェアの考え方に少しでもオープンであれば、AGPLやGPLなどのフリーライセンスまたは他のフリーソフトウェアライセンスでプログラムを作成できます。私が見たことから、ソフトウェアのソースが何らかの理由でそれを改善するために開発者にそれ以上興味を引かないとき、ソースベースは共食いされて、新しい生活を引き受けます。Debianオペレーティングシステムのパッケージは、私が見た限り、このライフサイクルに従う傾向があります。

さまざまな政府および民間産業のアプリケーションをサポートしてきたことから、ほとんどの企業および少なくとも米国政府は、コードを腐敗させ、最新のセキュリティトレンドを把握しないことの危険性を十分に認識していると思います。

私たちは定期的にさまざまな感受性のソフトウェアを認証する必要があり、ほとんどの政府の電子システムは、古いものであっても、それらを安全に保つために定期的な更新を取得します。

もちろん例外もあり、ハッカーは常に動いていますが、全体としては、何かを投げ捨てて二度と触ることはできないと、人々はかなり気づいていると思います。

警告：これは少し自由形式になります...

あなたの懸念を見るには2つの方法があると思います。

考えてみると、一部のスペースシャトルと衛星は、元々それらを打ち上げたのと同じコードを実行しています。一方で、一部は（非常に）リモートであっても更新されるように設計されています。

重要なのは環境です。明らかに、環境を変更しない限り、コードは時代遅れになりません。この場合、コードの腐敗は実際には存在しません。コード自体（または生成されたバイナリ）は腐敗できません。まったく異なる角度から攻撃を開始すると、壊れる可能性があります。腐敗しているということではなく、環境に適応していないということです。進化の問題と考えてください。

しかし、環境は変わります。そしてどういうわけか、あなたの問題の鍵は解決策でもあります。私たちの環境は非常に急速に変化するため、現在ではソフトウェアソリューションが時間とともに進化しないとは考えていません。過去1年間に更新されていないソフトウェアプロジェクトを見落とし、明確なロードマップを作成しない製品およびカスタマーサポートについて嘆きます。そして、これがうまく機能していても-明確なロードマップ、優れたサポート、定期的な更新を取得します--チャレンジャーが指数関数的に成長する可能性が常にあります。大企業は常に支配的であるという理由で、大企業が常に支配的であると誤解することがよくあります。ただし、群れの支配的な要素が古くなるのと同じように、超大規模なソフトウェア/ハードウェア/ベンダーが古くなるとは限りません。またはちょっと怠け者。そして、挑戦者がやって来て、5年か10年前に確立された支配者がそれをやったよりもさらに速く物事を好転させます。または、市場の混乱（経済的に言えば、さまざまな分野に影響を与える）を見ている間、優勢な人はかろうじて生き残り、その後、物事は続きます。不完全に見えるかもしれませんが、それ自体は有機的なプロセスです。

したがって、ユーザーの観点からは、問題はそれほど大きくないと思います。ユーザーの観点からはコードの腐敗は発生しません。ユーザーが代替手段を使用する可能性があるためです（シームレスな移行/移行が可能であれば...）。

今、ユーザーの観点から物事を見ていないか、または、理由がわからない、政府の開発、空間旅行など、免疫に耐えるシステムについて話していると仮定します。非常に長い期間生きて生き残るために構築するには、参照したテキストを調べる必要があります。そしておそらく、信頼できるシステムとフォールトトレラントシステムに関するいくつかの文献。おそらくさらにプッシュしたいと思いますが。耐障害性だけでなく、進化システムが必要です。

進化の問題は、それが変更を導入し、変更が障害点を導入することです。これらを今すぐ見て、それらに対処するためにできることを見てみましょう。

インフラストラクチャ/アーキテクチャ/ emgineeringのメタファーに依存することもできます（結局のところ、ソフトウェアエンジニアのようなものはおそらく今のところありませんが、ソフトウェアエンジニア全員です）。チューブシステムがまだアクティブになっている（何らかの不具合がある）一方で、ビッグベンがまだ動作している（何らかの不具合がある）か、エッフェル塔がまだ立っているのには理由があります。それは、インフラストラクチャの重要な（またはそれほど重要ではない）要素を使用してソフトウェアで行うべきこと、つまり継続的な検査を行うためです。これらのエンティティは、必ずしもこのように長持ちするように設計されているわけではありませんが、必要に応じて恒久的な監視とタイムリーな改善と修理の恩恵を受けています。必要に応じて、修正プログラムを呼び出します。

一方、一部の設計は、継続的な検査が不可能であることを知っていても、持続し、中断することなく永続的に実行することを目的としていました。この場合、優れた設計と正式なモデルに目を向けます。信頼性の要素（可用性、信頼性、安全性、整合性、保守性）は、特定の環境に対して定量化できます。統計は、残りと将来を計画するために残りを行います。それは疑問をもたらします：本当の意味で進化するシステムを構築することさえ可能ですか？

クリーンコードのジェフランガーは、同様の質問をしています...蒸気管への言及なし:)

従うことができる4つの単純なルールがあり、作業中に良いデザインを作成するのに役立つとしたらどうでしょうか。これらのルールに従うことで、コードの構造と設計に関する洞察を得て、SRPやDIPなどの原則を簡単に適用できるようになったらどうでしょうか。これら4つのルールが優れたデザインの出現を促進したとしたらどうでしょうか？

私たちの多くは、ケントベックの4つのシンプルデザインルールが、適切に設計されたソフトウェアを作成する上で大きな助けになると感じています。

Kent（Extreme Programming Explained）によると、デザインは次のルールに従っていれば「シンプル」です。

• すべてのテストを実行します
• 重複はありません
• プログラマーの意図を表現する
• クラスとメソッドの数を最小限に抑える

すべてのテストを実行するには、実行するテストが必要です。これは技術的負債の大きな指標です。たとえば、Mercury Quality Centerなどのシステムに10,000件のテストケースがあり、それらのテストがいずれも自動化されていない場合、蓄積された技術的負債の明確な指標の1つです。

そして、そこがFeathersと彼の著書「レガシーコードで効果的に作業する」の出番です。