大規模なレガシーアプリケーションを「オーバーホール」するにはどうすればよいですか？
次のプロジェクトでは、多くのパーツを含む大規模なレガシーWebアプリケーションの「オーバーホール」を担当しました。それは2004年に書かれたJSPアプリケーションであり、私の会社で頻繁に使用されています。
このアプリケーションは、懸念事項の分離がないという点でひどく設計されました。サービス層、DAO層、MVC構造はありません。 HTMLと混合されたロジックとデータベースクエリを含むスクリプトレットがロードされた一連のJSPファイル。それは混乱です。
私の上司は、「オーバーホール」を基本的に、最近のアプリケーションに使用するテクノロジーを使用して全体を書き直すことと定義しています。
- メイベン
- 春
- JPA（休止状態あり）
- JSF
[〜＃〜]および[〜＃〜]は、新しい機能の束を追加します。
私の質問は、どうすればよいですか？現在使用中の大規模なアプリケーションを完全にやり直し、一連の機能を追加するための戦略は何ですか？
最初に既存のアプリケーションを書き直して、更新されたテクノロジで動作させる必要があります。その後、新しい機能の追加について心配する必要がありますか？それとも、まったく新しいアプリケーションを作成し、古い機能を使用して新しい機能を実装するようにするべきでしょうか？
誰かがこれを成功させましたか？もしそうなら、どの戦略があなたの成功に役立ちましたか？
編集：コメントからの詳細情報：
書き換えを正当化するために、設計はどれほど悪いものでなければなりませんか？このデザインはかなり悪いです。アプリケーションには多くのビジネスロジックが隠されています。仕様、要件変更のログ、バグ修正のリスト、未解決のバグのリスト、テストスイート、ドキュメントはありません。そして、最初にそれを書いた人は現在、上級管理職にいます。
アプリケーション全体を書き直すことはお勧めしません。特に現在お客様が使用されているもの。古いシステムでできることをすべて実行できるようになるまで、新しいシステムに切り替えることはありません。あなたが新しいシステムを書いている間、顧客と経営陣は焦り、それらの新機能を求めます。あなたまたは他の誰かがそれらを古いアプリに追加する必要があります。これにより、新しいアプリから時間がかかり、完了する前に行う必要のある作業が増えます。終わりのないプロジェクトに参加していると感じ、モラルが低下し始めるまで、時間が経つにつれ、実際にプロジェクトを完了する可能性は低くなります。
一般的に、悪い考えです。上記のMichaelTリンクのとおり。
代わりに何をすべきか？
現在のコードベースをよく調査してください。良い、悪い、醜い、そして恐ろしい右を見つけてください。すばやくクリーンアップできるもの、再利用およびリファクタリングできるもの、使用されなくなったか不要になったもの、書き直しが必要なものを確認します。
新しいDALを設計して実装します。ページとコードを確認し、もつれをほどくと、DALを呼び出す別のビジネスレイヤーができます。一度に同じようなページに焦点を当てます。それらがクリーンアップされて準備ができたらリリースします。より反復的にします。これらのページを2回以上ヒットする必要があるかもしれませんが、毎回より良いままにしてください。
新しい機能が導入されると、現在パイプラインにあるもの以上のものを手に入れ、それらをクリーンアップ作業に組み込みます。新しい機能をリリースするときは、同時にクリーンアップされた新しいコードをリリースします。
これにはしばらく時間がかかりますか？はい。はい、そうです。私は現在の会社に3年間在籍しており、クリーンアップしてきたWebクライアントアプリケーションは完了していません。しかし、多数のメジャーリリースがあり、それを多くの異なるクライアントに販売しました。今ではより多くのプラットフォームで動作し、新しいページや機能を作成することがますます簡単になっています。ゼロから始めて、完了したらリリースすることに決めていたとしても、それはまだ進行中の作業であり、メジャーリリースやクライアントを示す必要はありません。
このアプリケーションにはどのくらいのビジネスロジックが隠されていますか？最初に完全な仕様はありますか？すべての要件は過去10年間で変化しますか？修正されたすべてのバグ？まだ開いているすべてのバグ？包括的な回帰テストスイート？
答えられたのは...
書き換えを正当化するために、設計はどれほど悪いものでなければなりませんか？このデザインはかなり悪いです。アプリケーションには多くのビジネスロジックが隠されています。仕様、要件変更のログ、バグ修正のリスト、未解決のバグのリスト、テストスイート、ドキュメントはありません。そして、最初にそれを書いた人は現在、上級管理職にいます。
10年前のアプリケーションがあり、実際に何をすべきか、それを修正するために何が行われたか、何が正しく機能していないかについてのドキュメントはありません。
2つの方法があります。
1つ目は、内部からゆっくりと書き換えることです。入ってモジュールを見つけ、それが何をすべきか、何をすべきかを正確に理解し、それを置き換えます。これは段階的なプロセスです。それはおそらく最良のアプローチです。それは経営者が好む傾向があるものではありません（経営者は見た目が大きく、リリースが大きい大きなプロジェクトを好む傾向があることを発見しました）。何もしていないように見える内側から何かを交換しても、称賛は得られません。
もう1つのアプローチは、元のファイルを捨てて最初からやり直すことです。問題は、「これにはどのくらい時間がかかるか」です。尋ねられる最初の質問の1つです。このため、妥当な見積もりを得ることができます。
ドキュメントがない場合は、完全に書き直し、アプリケーションが持っているコードの行数を調べ、それを COCOMO II モデルに放り込みます。これは、現在存在しているのと同じくらい多くのコード行が新しいコードを書くのにかかることを想定して機能します。それがどれほど大きいか見てください。
問題は、ビジネスが着手すべきこれは、プログラマとして私たちが作るべきものではないということです。私たちはそれに意見を持っています、そしてこれはひどい時間の無駄だと思うかもしれません、またはこれはとても楽しいことだと思うかもしれません（私はこれを読むことを強くお勧めします Death March これについていくつかの視点を得る）-しかし、私たちがビジネスを求めるのは私たちではありません。
これにかかる時間枠を特定し、正当な投資収益があるかどうかをビジネスに判断させます。
3番目のオプションがあることに注意してください-そのままにしておきます。
誰かがこれを成功させましたか？
こちらが当社のサクセスストーリーです。かなり長い間、私たちは乱雑なウェブサイトを持っていました：
- PHP/MySQL、ほとんどDrupal 6。
- 多くのカスタムDrupal中品質のモジュール。
- プレーンなPHP + SQL + HTML + JS + CSSで書かれたいくつかの本当に古いレガシーコードパーツ（実際にそれらすべてを一度に含むファイルがありました）。これらは実際には、アプリケーションの古いバージョンからの非常に重要な部分でした。
- 2つの内部MySQLデータベース（1つはDrupalともう1つは古いもの用）、2つは外部SQL Serverデータベースであり、アプリが統合されています（すべて直接クエリのみ）。
- 仕様もテストもリポジトリもありません（後で作成しました）。
- 現在、コードベースのサイズはわかりませんが、約12のカスタムフォームと約10のカスタムDrupalモジュールがあります。多くの機能は、公式のDrupalリポジトリなので、私たちが書いたり保守したりするコードの一部として数えるべきではありませんが、リライトはコハナフレームワークで行われたので、すべてを一からやり直しました。
良いニュースは：
- やり直す前に、私はこのアプリの1年以上のメンテナンス/拡張の経験をしました。私の同僚の2人は、そのような経験の時間を約2倍短縮しました。最後の一人は経験がありませんでした。
- メンテナンス期間を通じて、一部のパーツを徐々に改善し、ほとんどの落とし穴と文書化されていない機能を見つけました。
- 書き直す前に、なんらかの仕様を作成することに成功しました。
- 過去数か月の間に、新しいバージョンで維持する予定の新しいパーツをいくつか追加しました。このコードの一部は実際に移植されました。
それが起こった方法：
- それは主に2人の男によって行われました、彼らのうちの1人はメンテナンス経験のない男でした。私はスペックとコードを少し手伝いました。 1人の男がプロセスを通じて古いバージョンを維持しました。
- 半年以上かかりましたが、マネージャーが新しいインターフェースのコンセプトとグラフィカルなデザインを得ることにこだわったことが一因です。コーディングだけで4〜5か月で完了できると思います。
- ほぼすべての古い機能が実装され、一部はわずかに改善されています。
- 初歩的な単体テストが行われましたが（TDD/BDDではありません）、まだ調べていません。
結局、新しいバージョンがオンラインになり、大きな問題はありません。
次の理由により、100％の書き換えではありませんでした。
- 新しいバージョンにいくつかの（ただし少し）コードを取り込みました
- 古いバージョンは実際には段階的な改善のプロセスを経ていたので、開発者としての私たちにとって大きな「パラダイムシフト」ではありませんでした
それだけのメンテナンスがなければ、おそらくそれはできなかったでしょう。完全な書き直しは一般的に悪い考えであるという点で、私は他の回答に同意する傾向がありますが、私たちの物語が示すように、これらの条件を前提として可能です。
- アプリはそれほど大きくありません
- チームはそれほど大きくありません（この例では4）
- ほとんどのチームメンバーは、レガシーコードを扱う広範な知識と経験を持っています
あなたの特定の状況について、私はあなたに提案することができます：
- あなたが持っているものを改善してみてください。これにより、少なくともアプリについての深い知識が得られます。
- 改善が機能する場合は、現在のテクノロジースタックに切り替えなくても、改善を続けることを検討してください。手の中の鳥は、茂みの中では2匹の価値があります。
- リストの1節により、改善が失敗した場合でも、書き換えがより簡単で高速になります。