什麼是審計大型java/j2ee web應用程序的最佳方法

Question

我必須審覈一個大型的網頁Java/J2ee應用程序，這個應用程序已經發展了幾個 年。它是由其他公司編寫的，而不是我爲之工作的公司。在 目前的狀態下，它變得難以發展和維護，新的功能難以添加，並且經常導致某些時候在 生產中出現的錯誤。似乎有一些複製/粘貼的代碼導致代碼重複。 目前的應用程序是某種在線購物，在這裏和那裏都有一些類似cms的內容。 它主要是Struts和一些Spring代碼的新部分，也許有些ejbs拋出了 好的措施。有一些單元測試可用，但不是很多。 這些都是我被告知的事情，我還沒有看到實際的代碼。

我的公司將提出重寫這個應用程序的部分內容，以便減少複雜性，提高質量和模塊性，並且可以在沒有迴歸的情況下添加更容易的新功能。 在做出任何提議之前，他們想要對現有代碼的質量有一定的讚賞，並評估它可以重複使用的數量，以便 對必須有的東西有更多的猜測完成 - 完全重寫或重寫 。

問題是，我必須在很短的時間內（幾天）這樣做，所以我 試圖制定一個計劃，在這麼短的時間內可以完成的事情。什麼我thiking是：

• 退房「基本」的東西 - 例外處理，記錄
• 退房分層（視圖，控制器，DAO層）的水平
• 測量的實際覆蓋單元測試
• 也許運行一些的Checkstyle，FindBugs的和PMD在項目
• ...

所以實際的問題是什麼其他的事情SH我應該考慮/檢查/測量/等嗎？

我不知道我能擺脫這種什麼樣的數字，如果它真的意味着 的東西，我的感覺是什麼樣的管理要求是一種錯誤的做法 的，所以第二個問題會是：有沒有人有更好的主意？

我會感激任何想法，建議，對此發表評論。

編輯：我會加入兩個死代碼檢測到組合：UCD和DCD

Answer 1

我有兩個與您具有相似設置的Web應用程序。我停止使用FindBugs和Checkstyle，因爲它們顯示了超過10,000個問題點。這些應用程序使用JDBC級數據訪問，用於演示的JSP和用於請求調度的定製框架。幸運的是，這些低級設置讓我可以在中等難度上進行擴展和修復。在3年的項目中，原始代碼中只有大約20％保持原樣。遲早或其他一切需要更改，替換或刪除（最後我能夠使用FindBugs和Checkstyle）。

我們也面臨着完全重寫的困境。但是，有幾個因素會對它造成影響：

• 不確定客戶是否支付全部重寫費用。
• 缺少功能和技術文檔使完成重寫變得很冒險。
• 完全瞭解完整應用程序的工時太高。客戶希望儘快提出要求的更改。
• 定製演示文稿和頁面行爲的用戶。似乎很難說服用戶使用舊功能的新界面。
• 如果我們做一個完整的重寫，我們需要提供完整的文檔。爲了更新，我們只需要記錄我們的部分。
• 如果程序正常工作（或多或少），很難說服管理層（自己和客戶）重寫
• 公司有自己的PMD規則，代碼沒有通過。認爲新部件通過測試就足夠了，這是比較簡單的。

它簡化了你想要做的事。

你想重寫嗎？儘管複雜嗎？

• 強調代碼錯誤。帶有大量紅色的大餅圖很有說服力。
• 解釋程序屬性以及它們如何不符合企業願景。
• 顯示超出當前要求的增強選項並描述當前版本未能應對挑戰。
• 與真實用戶進行訪談。他們可能會指出當前版本的重要問題。
• 便宜，但一個很好的估計。您可能會延遲一些費用直到維護階段。

你不想重寫？

• 重視成本，特別是客戶要求重新測試一切的工時。
• 指出破壞功能的潛在麻煩。
• 請求全職文檔撰稿人。

如果您想品嚐代碼，請嘗試添加Hello World！功能/屏幕到應用程序。這說明你可以多麼努力地執行新事物，並且有多快。

Answer 2

我喜歡你的清單上不少。我認爲你有一個很好的攻擊計劃。

我會着眼於在Spring或EJB 3.0上進行標準化，但不是兩者兼而有之。

我沒有看過它自己，但我不知道邁克爾羽毛的書"Working Effectively With Legacy Code"有什麼好主意嗎？

UPDATE：

也許你可以通過把它們放在自動構建和持續集成幫助的東西 - 巡航控制系統，哈德森，或團隊市。如果你必須做任何重構，它會有所幫助。

Answer 3

您關注的是可維護性和可擴展性。

我想補充一下，重啓項目需要多長時間。他們是否使用源代碼管理？他們是否有獨立的集成和用戶驗收測試環境？是否有構建服務器？

如果您必須在第一次改進之前花費兩個月時間，則需要預先處理客戶的期望。

Answer 4

事實上，他們不會支付全部重寫，因爲：

• 這是經濟衰退，你從頭開始重寫它的成本會很高

• 他們可能會嘗試出售該公司儘快

• 管理層並不瞭解關於軟件開發的任何

我會先用一些簡單的事實去：

• 使用工具顯示項目
• 運行的SLOC，你計劃的FindBugs並最終PMD，只是估計缺陷
• 進行快速分析會議
• 檢查不同層
• 看看資源通常關閉（數據流，Hibernate或者JDBC連接等）
• 看看技術都用到哪裏不適用（EJB，Web服務，等等。 ）
• 看他們如何處理異常和記錄
• 看看是否有太多或沒有足夠的抽象
• 看看你是否可以添加一些基本類，以減少代碼的重複

嘗試繪製的快速圖應用程序的架構，如果他們不給你一個關於它的文檔。

收集一些統計數字和一些事實，寫一份報告並將它們發送給公司。他們會想要最小化成本，他們會要求您避免修復未破壞的代碼。您先從統計數據開始，然後根據時間/受影響代碼/定價的大致百分比來確定事實和命題。

通常遺留的Struts應用程序是一個維護的皮塔，在那裏做了。如果這不是你工作的一部分，我會放過它。如果您遇到不涉及許多模板且受到許多更改的「獨立」頁面，建議用其他技術重寫它們。