15

数年かけて進化した大規模な Web Java/J2ee アプリケーションを監査する必要があります。私が働いている会社ではなく、他の会社によって書かれています。現在の状態では、進化と保守が難しくなり、新しい機能を追加するのが難しくなり、本番環境でバグが発生することがよくあります。コードの重複を引き起こしたコピー/貼り付けコードがいくつかあるようです。現在のアプリは、いくつかの cms のようなコンテンツがあちこちにあるオンライン ショッピングです。それはほとんどが Struts であり、コードの新しい部分にはいくつかの Spring が含まれています。利用可能な単体テストがいくつかありますが、多くはありません。これらは私が言われたことであり、実際のコードはまだ見ていません。

私の会社は、このアプリの一部を書き直して、複雑さを軽減し、品質とモジュール性を改善し、リグレッションなしで新しい機能を簡単に追加できるようにすることを提案します。コミットメントを行う前に、彼らは既存のコードの品質をある程度評価し、再利用できるコードの量を評価して、何をする必要があるかについて推測以上のものを得たいと考えています。書き直しまたは部分的な書き直し。

問題は、これを非常に短い期間 (数日) で行わなければならないことです。そのため、このような短い時間で何ができるかについて計画を立てようとしています。私が考えているのは：

  • 「基本的な」ことをチェックしてください - 例外処理、ロギング
  • 階層化のレベルを確認してください (ビュー、コントローラー、dao レイヤー)
  • 単体テストの実際のカバレッジを測定する
  • プロジェクトに対してCheckstyle、Findbugs、PMDを実行するかもしれません
  • ...

したがって、実際の問題は、他にどのようなことを考慮/チェック/測定/などする必要があるかということです。

これからどのような数字が得られるかはわかりませんが、それが本当に何かを意味する場合、経営陣が求めているのは一種の間違ったアプローチであると感じているので、2番目の質問は次のとおりです。より良いアイデアですか？

これに関するアイデア、提案、コメントをいただければ幸いです。

編集：ミックスに2つのデッドコード検出器を追加します：UCDとDCD

4

4 に答える 4

8

あなたと同様の設定の 2 つの Web アプリケーションがありました。FindBugs と Checkstyle は 10.000 以上の問題点を示したので使用をやめました。アプリケーションは、JDBC レベルのデータ アクセス、プレゼンテーション用の JSP、リクエスト ディスパッチ用のカスタム フレームワークを使用しました。幸いなことに、これらの低レベルの設定により、中程度の難易度で拡張と修正を行うことができました。3 年間のプロジェクトの間、元のコードの約 20% だけがそのまま残っていました。遅かれ早かれ、他のすべてを変更、置換、または削除する必要がありました (そして、最終的に FindBugs と Checkstyle を使用できるようになりました)。

私たちも完全な書き直しのジレンマに直面しました。ただし、それにはいくつかの要因がありました。

  • 顧客が完全な書き直しに対して支払うかどうかわからない。
  • 機能や技術に関するドキュメントが不足しているため、完全に書き直すのは危険です。
  • 完全なアプリケーションを完全に理解するための工数が多すぎました。顧客は、要求された変更をより早く望んでいました。
  • プレゼンテーションとページの動作に慣れているユーザー。古い機能に新しいインターフェイスを使用するようにユーザーを説得するのは難しいようでした。
  • 完全な書き直しを行う場合は、完全なドキュメントを提供する必要があります。更新のために、私たちの部分だけを文書化する必要がありました。
  • プログラムが (多かれ少なかれ) 機能する場合、管理者 (自社および顧客) に書き直しを納得させるのは困難です。
  • 同社には独自の PMD 規則があり、コードは通らなかった。新しい部品がテストに合格すれば十分だと主張する方が簡単でした.

それはあなたが実際にやりたいことを要約します。

複雑なのに書き直したいですか？

  • コードのバグに重点を置いてください。赤をたくさん使った大きな円グラフは説得力があります。
  • プログラムの特性と、それらが企業のビジョンにどのように適合しないかを説明してください。
  • 現在の要件を超える拡張オプションを示し、現在のバージョンがどのように課題に対応していないかを説明します。
  • 実際のユーザーにインタビューを行います。彼らは、現在のバージョンの重要な問題を指摘するかもしれません。
  • 安くても良い見積もりをしてください。メンテナンス フェーズまで一部のコストを遅らせることができます。

書き直しませんか？

  • コスト、特に顧客がすべてを再テストするために必要な工数を重視します。
  • 機能を壊す潜在的な問題を指摘します。
  • フルタイムのドキュメントライターを依頼してください。

コードを味わいたい場合は、Hello World! を追加してみてください。アプリケーションへの機能/画面。これは、新しいことをどれだけ早く実装できるかを示しています。

于 2009-06-21T18:28:55.113 に答える
2

あなたは保守性と拡張性に焦点を当てています。

プロジェクトを再起動するのにどれくらいの時間がかかるかを調べて追加します。彼らはソース管理を使用していますか? 統合とユーザー受け入れテスト用に別々の環境がありますか? ビルドサーバーはありますか？

最初の改善が現れるまでに 2 か月を費やさなければならない場合、誰かがクライアントの期待を前もって管理する必要があります。

于 2009-06-21T15:29:00.830 に答える
2

私はあなたのリストがとても好きです。開始するための優れた攻撃計画があると思います。

私は、Spring または EJB 3.0 のいずれかで標準化することを視野に入れていますが、両方ではありません。

私自身は読んだことはありませんが、Michael Feathers の著書「レガシー コードを効果的に使用する」に何か良いアイデアがあるのだろうか?

アップデート：

おそらく、自動ビルドと継続的インテグレーション (Cruise Control、Hudson、または Team City) にそれらを配置することで、物事を助けることができます。リファクタリングが必要な場合は、それが役立ちます。

于 2009-06-21T13:44:57.093 に答える