ソフトウェアの成功/失敗率の書き換えに関する実際のケーススタディはありますか？

私は、アプリケーションの書き直しが悪いことについての複数の投稿、プログラマに関するここでの人々の経験、およびこのテーマに関するJoel Spolskyによる準備ができた記事を見ましたが、確固たる証拠や事例研究はありません。Joelが提供した2つの例とここの他の投稿以外に、悪いコードベースで何をし、実際の研究に基づいてどのようにそれを行うかを決定しますか？

適切な例として、私が知っているクライアントは2つあり、どちらも古いレガシーコードを持っています。彼らは、書き直しが惨事であり、費用がかかり、コードを大幅に改善することが実際にはできなかったため、彼らはそれに合わせてリンプを続けています。リライタがすぐに見つけたように、その顧客は非常に複雑なビジネスロジックを持っています。

どちらの場合も、これらは企業にとって多くの収益をもたらすミッションクリティカルなアプリケーションです。書き直そうとした人は、将来のある時点でレガシーソフトウェアがアップグレードされなければ、レンガの壁にぶつかると感じていました。私にとって、この種のリスクは、成功する道を確保するための研究と分析を必要とします。

これを調査した実際のケーススタディはありますか？実際の研究に基づいたいくつかのベストプラクティス、落とし穴、成功を知らずに、大規模な書き直しを試みたくありません。

あとがき： さて、さらに検索した結果、ケーススタディに関する3つの興味深い記事が見つかりました。

1. 書き換えまたは再利用。彼らはJavaに変換されたCobolアプリの研究を行いました。
2. もう1つは、ソフトウェアの再利用：開発者の経験と認識に関するものでした。
3. 再利用または書き換えメンテナンスと書き換えのコストに関する別の研究。

最近、このテーマに関する別の記事を見つけました：The Great Rewrite。そこで、著者は主要な問題のいくつかにぶつかったようです。これに加えて、提案された新しいテクノロジースタックを使用し、開発者がそれを拾った速さを測定することによるプロトタイピングのアイデアがありました。これはすべて書き直しの前奏曲であり、素晴らしいアイデアだと思いました！

私はこれらの素晴らしいコメントを信用することはできませんが、元の著者による回答に決して入れられなかったので、コミュニティwikiとマークしています。

私はケーススタディについては知りませんが、アプローチの標準的な答えはおそらく「ユニットテストを追加してリファクタリングすること」だと思います。

おそらく、最もリスクの低いアプローチとして利用できると思います。もちろん、それが正しいアプローチであると確信するのに十分な詳細は知りませんが、私がこれまでに知ったことに基づいて、私は特にずっと良くなる可能性が高いことを知りません。

ユニットテストを行う場合（適切に-すべての要件を真に把握する）、リファクタリングを行って真の災害をもたらす方法を見つけるのは困難です。起こり得る最悪の事態については、あなたが望むほど速く進まないということです。同時に、質問が暗示しているようにコードベースの形が悪い場合、進む経路に関係なく、進行を可能にするために深刻な努力が必要になる可能性はかなり高いです。

書き換えプロジェクトは、一般的なプロジェクトと比べて失敗率に大きな違いはないと想定し、最良の情報については最新のCHAOSレポートを参照します。

マイケルフェザーズによるレガシーコードを効果的に使用することをざっと読みましたが、テストの記述（コードの目的がわからない場合でも）やコースのリファクタリング/書き換え。少し古くなっていますが、Amazonで高い評価を受けています。

経験から言えば、最初からエンタープライズアーキテクチャの構想が不十分な会社に住んでいるということは、正直なところ、最大の問題は包括的な理解を深めることです。

システムを細分化して個別に理解できるというこの考え方には欠陥があります。ある時点で、1人の個人または複数の個人が、問題全体を全体として考えなければなりませんでした。その問題が一連のビジネス上の問題とそれらを推進するテクノロジーである場合; 社内の人がすべてのシステムを理解し、災害や要件を満たさないままシステムを交換できるレベルまで理解するには、数年かかる場合があります。私がテクノロジーディレクターを引き継いだとき、これは確かに私の会社の場合でした。私が自分がコーダーであるという事実がなかったら、うまく組織化されておらず、緊密に結合され、緊密に結合されたアーキテクチャとテクノロジーの統合のすべての詳細をゆっくり理解することはできなかっただろう。以下のような小さな隠された、文書化されていない詳細の場合"We put the eBay order number in the "SYSOENT.PO_NUMBER" field in the ERP system because that's what Wendell the VB coder from Florida decided to do" 見落とされている結果は悲惨なものになる可能性があり、これを知る唯一の方法はすべてをゆっくり発見することです。

飛行中に航空機のエンジンを交換するか、特定の死に直面するように求められた場合-適切な量のツールとリソースを考えると、個人がセンサー、油圧システム、燃料フローを再ルーティングする方法を知る必要があります、外部またはコックピットから変更または操作されるように設計されていないシステムを操作します。多くの場合、これはビジネスアプリケーションを書き換える見込みです。通常、アプリケーションは他の多くの異なるテクノロジー間のビジネスに組み込まれます。

私の第一のポイントは、システムがほぼ完全に複雑であると理解されなければならず、新しいシステムが「作られた」だけでなく適切に「設計」されるためには、ある時点で完全性が理解されている必要があると思います。

Cookieが作成され、ソフトウェアが設計されるべきです。

Netscapeのように、書き直しで亡くなった企業の多くの例があります。ツイッターのような大きなトラブルなしに書き換えを生き延びた企業もあります。

定量化されたケーススタディはありません。書き換えなしのビジネスの成功と書き換えのビジネスの成功を比較するコントロール実験を行うのは現実的ではないからです。すべてのアプリケーションは異なります。

リライトが理にかなっている明らかなケースとそうでない多くのケースがあります。書き換えがあなたの場合に意味があるかどうかを判断するために、私は少しレシピを作り上げました。

Rails、Grails、AngularJSのような侵襲性のあるフレームワークを改善するために、私たちは迅速にコーディングしているので、最近は書き換えがより意味があると思います。プレーンjsからAngularに移行したい場合、書き直しがあなたにできることのほとんどです。それはまだ意味をなさないかもしれません。あるdiyの実装を別の実装に置き換える場合（Joel Spolskyの記事にあるすべての例のように）、おそらくおかしいでしょう。

アクションレポートの後以外の多くの偏りのないケーススタディを見つけることはありません-ほとんどの人は、同じ作業を2回以上実行するためにお金を払うつもりはありません（書き換えとして、一度アップグレードとして、最高です）ケースは、異なるチームによる複数の書き換え/アップグレードになります）。

あなたが見つけたケーススタディは富士通によって作成されたようであり、当然の結果として富士通のツールを使用した方が良いという結果になりました。

組織的な観点からは、書き換えは、書き換えられたアプリケーションが機能しない場合、またはプロジェクトが終了前にキャンセルされた場合にのみ明らかに失敗します。そうでない場合、書き換えられたバージョンのリリースの遅延が原因であったかどうかを知ることは不可能ですあなたが被った損失の原因または単なる偶然。終了する前にキャンセルされた場合、一般的に時間とリソースの総無駄とみなされます。アップグレードでも同じ問題が発生する可能性がありますが、インクリメンタルであることは同じ規模になることはほとんどありません（お金で何かを手に入れることができます）。

プログラミングの観点からのベストケースは、両方を実行することです。書き換え中のインクリメンタルアップグレードであり、お互いをサポートし、刺激します。異なるチームがない限り、これには当然時間がかかります。

これは、完全な書き換えを検討する必要がある場合の大まかなガイドラインを提供することに注意してください。プロジェクトは簡単にできるほど小さいか、またはオーガナイゼーションが十分に大きいため、両方を行う余裕があり、努力や学習コストをカウントします価値がある。また、リライトがリワークに追い付かない場合、それはいくつかのことを意味する可能性がありますが、他のすべてが等しい場合、おそらくリライトが不要であったことを意味します。