Spring Java EE中的大規模重構

Question

我正在對Spring-Java EE商業應用程序進行大規模的重構。然而，所有的重構都將在我們用作實用類（驗證器，算法，對象處理邏輯，資源管理，漂亮工具等）的許多靜態類中，而不是在控制器和持久性類中。

此外，使用這些靜態工具類中的方法的關鍵控制器不會受到影響，因爲我正在使更改儘可能透明。

事情是，我是一些控制器的所有者，所以我可以進行任何必要的更改以促進我的靜態實用程序類中的更改。例如，如果我更改了一個引發自定義異常的方法，那麼我也可以進入控制器並優雅地處理該異常。

但是，這是一個大型項目，還有許多其他開發人員正在研究它，其中許多人日復一日地使用這些靜態工具類。所以，如果我拋出新的異常，創建新的重載等，它將打破遺留代碼。

我已經厭倦了寫非兼容的（閱讀：殘缺的）代碼，這些代碼不是語義的，包裝了現有的醜陋邏輯，並且不允許我做出更靈活的設計。考慮到我們距離生產日有一段不錯的（精確的：2個月）的距離，我可以要求所有開發人員按照我的新合同重構他們的代碼，或者我繼續寫下遺留問題，垃圾包裝的代碼不能真正幫助任何東西？

Answer 1

• 在一個新的（乾淨的）包中，甚至可能是jar中執行你的新代碼。
• 將現有的遺留代碼更改爲「適應」並委託/轉發到新實施。
• 要求消費者遷移到新包裝。

這樣使用新的東西，人們沒有看到「舊式垃圾包裹代碼，並不能真正幫助任何」，但你確實提供了前進的道路並非所有客戶都立即更改所有代碼（並且在使用新代碼的實現中，您提供了明確的文檔，說明他們應該使用的代碼而不是舊的方式）。

順便說一句，許多靜態類聽起來不像最可測試的代碼庫。您是否考慮過使用更多的「實例」功能並將實例注入消費者，這通常會使代碼更易於測試...

Answer 2

我說改變它並打破所有值得破解的代碼。你需要支持哪些其他開發者？ Stroustrup/Gosling的後代入侵VM？我不打賭。

我一直都在你現在的位置，我不得不忍受那些要求我禁止所有（新引入的）算術例外函數的imbeciles，因爲所有他的對該函數的調用都沒有一個簡單的例外chewer。他的模塊會很快樂，儘管語義已經被嚴重破壞了，你能想象嗎？讓我們有足夠的錯誤來解決。

不要忍受任何不合格的東西，或任何形式的妥協。現在打破它，並建立它更乾淨，更精簡。人們首先會跺腳，並且會造成一場慘敗，但如果你正在寫更好的（更強大和更優化的）代碼，他們最終會意識到這一點。時間問題。

我同意弗裏德，這些「實用」方法太多的靜態類不是一個好主意。它感覺比00更程序化。嘗試根據業務方面對行爲和狀態建模。

E.g.如果你有一個賬戶類，並且想要編寫幾個實用程序類來執行諸如賬戶設置，賬戶刪除，賬戶轉移等任務，你最好走基於實例的道路並使用對象建模真實狀態+行爲方式。更可測試，更多語義，更可讀，更少的靜態程序雜波。

祝你好運。

Answer 3

說真的，你爲什麼問我們，而不是你們的團隊？那就是你的問題。