ソフトウェアの成功/失敗率の書き換えに関する実際のケーススタディはありますか？
アプリケーションの書き直しが悪いことに関する複数の投稿、プログラマーに関するここでの人々の経験、そしてこの件について Joel Spolsky が用意した記事を見ましたが、確固たる証拠やケーススタディはありません。ここでJoelが示した2つの例と他のいくつかの投稿を除いて、悪いコードベースで何をし、実際の研究に基づいてそれをどうするかをどうやって決めますか？
適切な例として、私が知っている2つのクライアントがあり、どちらも古いレガシーコードを持っています。彼らの1人が気づいたように、書き換えは大惨事であり、コストがかかり、コードの大幅な改善にはあまり役立たなかったため、彼らはそれとともに足踏みを続けています。その顧客は、リライターがすぐに見つけたので、いくつかの非常に複雑なビジネスロジックを持っています。
どちらの場合でも、これらは会社に多くの収益をもたらすミッションクリティカルなアプリケーションです。書き換えを試みた人は、レガシーソフトウェアが将来のある時点でアップグレードされない場合、レンガ壁にぶつかるだろうと感じていました。私にとって、そのようなリスクは、研究と分析が成功の道を確実にするために必要です。
これを調査した実際のケーススタディはありますか？実際の研究に基づいていくつかのベストプラクティス、落とし穴、成功を知らずに大規模な書き換えを試みたくありません。
Aftermath：わかりました、さらに検索した後、ケーススタディに関する3つの興味深い記事を見つけました。
- 書き換えまたは再利用 。彼らは、Javaに変換されたCobolアプリについて調査しました。
- もう1つは Software Reuse：Developers Experiences and Perceptions でした。
- 再利用または再書き込み 保守と再書き込みのコストに関する別の調査。
最近、この件に関する別の記事を見つけました： The Great Rewrite 。そこで著者はいくつかの主要な問題にぶつかったようです。これに加えて、提案された新しいテクノロジースタックを使用してプロトタイピングを行い、開発者がそれをどれだけ早くピックアップしたかを測定するというアイデアがありました。これはすべて書き直しの前置きであり、素晴らしいアイデアだと思いました。
これらの素晴らしいコメントは信用できませんが、元の作成者がコメントに回答したことがないので、コミュニティwikiとマークしています。
ケーススタディについては知りませんが、アプローチの標準的な答えはおそらく「単体テストを追加してリファクタリングすること」だと思います。
それは、おそらく最もリスクの低いアプローチとして利用できます。もちろん、私はそれが正しいアプローチであることを確認するのに十分な詳細を知りませんが、私がこれまでに知っていることに基づいて、私は特にはるかに良くなる可能性が高いことをあまり知りません。
ユニットテストを行う場合（適切に-すべての要件を正確に把握している場合）、真の災害を引き起こすリファクタリングの方法を考え出すことは困難です。起こりうる最悪の事態については、あなたが望むほど速く進歩しないということです。同時に、それらのコードベースが質問が意味するように形が悪い場合、どのようなルートをとっても、進行を可能にするために真剣な努力が必要になる可能性はかなりあります。
書き直しプロジェクトは、プロジェクト全体と失敗率に大きな違いはないと想定し、最新のCHAOSレポートを参考にしてください。
私はスキミングしました レガシーコードで効果的に動作するMichael Feathers しばらく前に、それが現実世界へのいくつかの良い洞察を提供することがわかりましたテストの記述（コードの目的がわからない場合でも）を含むレガシーコードの保守、およびもちろんリファクタリング/リライトの実践。少し古いですが、Amazonで高い評価を受けています。
経験から言えば、最初からエンタープライズアーキテクチャの構想が不十分な会社に住んでいると、正直に言うと、最大の問題は包括的な理解を深めることです。
システムをバラバラに分解して個別に理解できるというこの考え方には欠陥があります。ある時点で、単一の個人または複数の個人が問題全体を完全に想像できる必要がありました。その問題が一連のビジネス上の問題とそれを引き起こすテクノロジーである場合。災害や要件を見逃さずにシステムを交換できるレベルまですべてのシステムを理解するには、数年かかる可能性があります。私がテクノロジーディレクターに就任したとき、これは確かに私の会社のケースでした。私自身がコーダーであるという事実がなければ、不十分に編成され、密結合され、緊密にバインドされたアーキテクチャとテクノロジーの統合のすべての詳細をゆっくりと理解することはできなかっただろう。 "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（---）のように、書き換えによって 死亡した企業の例はたくさんあります。 Twitter のように大きなトラブルもなく 書き直しに成功した企業もあります 。
書き直さないビジネスの成功と書き直しのビジネスの成功を比較する対照実験を行うのは現実的ではないため、定量化されたケーススタディはありません。アプリケーションはそれぞれ異なります。
書き換えが意味のある明らかな場合とそうでない場合が多くあります。あなたの場合、書き換えが意味があるかどうか を計算するための小さなレシピを作りました 。
Rails、Grails、AngularJSのような侵略的なフレームワークをこれまで以上に改善するという肩の上で迅速にコーディングしているので、今では書き換えがより理にかなっていると思います。プレーンなjsからAngularに移行したい場合は、書き直すだけで可能です。それはまだ意味のあることかもしれません。あるDIY実装を別のDIY実装に置き換える場合（ Joel Spolskyの記事 のすべての例のように）、おそらくおかしいでしょう。
アクション後のレポート以外に偏見のない多くのケーススタディを見つけることはできません-ほとんどの人は、同じ作業を少なくとも2回実行するために支払うつもりはありません（書き換えとして1回、アップグレードとして1回、最高）ケースは、異なるチームによる複数の書き換え/アップグレードです）。
あなたが見つけたケーススタディは富士通によって作成されたようであり、当然の結果として、富士通のツールを使用した方が良いという結果になりました。
組織の観点からは、書き換えは、書き換えられたアプリケーションが機能しないか、プロジェクトが完了する前にキャンセルされた場合にのみ明らかに失敗となります。それ以外の場合、書き換えられたバージョンのリリースの遅延が原因であったかどうかを知ることは不可能です。あなたが被った損失の原因、または単なる偶然の原因。完了する前にキャンセルした場合、それは一般的に時間とリソースの浪費とみなされます。アップグレードでも同じ問題が発生する可能性がありますが、増分であっても同じ規模になることはほとんどありません（お金で何かを得ることができます）。
プログラミングの観点からの最良のケースは、両方を実行することです-書き換え中の段階的なアップグレード、サポートと刺激の両方。異なるチームがない限り、これには当然時間がかかります。
これは、完全な書き直しを検討する必要がある場合の大まかなガイドラインを提供することに注意してください-プロジェクトはそれを簡単に行うことができるほど十分に小さいか、orgainizationは両方を行うことができるほど十分に大きく、労力または学習コストを数えることができます価値がある。また、リライトがリワークに追い付かない場合、それはいくつかのことを意味する可能性がありますが、他のすべてが等しい場合、リライトが不要であったことを意味していることにも注意してください。