我正在研究一個項目，其中的代碼庫大約有3500個文件，可能比實際少了幾百個。這個項目是用PHP編寫的，很麻煩，在這種情況下，這意味着文檔很難理解OOP，程序編程混雜，依賴不清，以及那些爲初學者程序員提供所有這些需求的人。選擇重構而不是完整重寫的標準
說實話，他們所做的是令人印象深刻的，它是一個工作產品，所有這一切。但調試和添加新功能是一件非常麻煩的事情。
現在到我的問題什麼是一些好的標準，我們應該重構整個項目或做一個完整的重寫。我應該提到，在我們去的時候重寫系統的一部分可能是不行的，因爲一切都是相互依賴的。
的基本標準將可能是時間（=金錢）。
當某個東西很大時，估計總是很難。將它分割成最小的塊。
注意觀點。你的估計可能會與之前的程序員估計不同，因爲它會偏向於你喜歡的風格。也許更好的選擇是聘請以前的程序員來「修復」代碼。
無論如何，您應該聲明最低要求來打電話給應用程序，寫得很好，易於維護， 與老闆和團隊討論這個問題，將其分解爲儘可能小的衝刺並估計所需時間。
如果您能夠說服您的老闆重寫將以更好的投資回報率整體返回，請重寫。否則，學習「新風格」。如果您在重寫期間停止業務或閒暇時間做到這一點，那麼您很幸運。如果代碼是可測試的，或者您至少有一些單元測試，那麼您更加幸運。 如果這是不可能的，你應該至少實現功能測試來幫助處理這兩種情況（重構或重寫）。
請注意，我們每個人都可能更喜歡重寫，而不是重構。 然後重寫這個改寫...
所以重構總是一個不錯的選擇，假設你已經有測試或者你能夠輕鬆地實現測試。
如果應用程序已經正常工作，並且沒有發生重大故障，那麼我會保留大部分功能，因爲從頭開始重寫所有內容始終代價高昂。
也許你應該考慮減少文件/行的數量，無論你看到重複的代碼製作對象/函數，儘可能地集中所有的東西。這對最終維護有很大幫助，並且不需要大量時間來完成。特別是如果它被寫入，就像你剛纔說的初學者一樣，你會很容易找到改進的「錯誤方法」。
如果應用程序很大，成功並且做了有趣的事情，嘗試用手重寫它可能會失敗。重寫將永遠不會有足夠的質量來取代原稿，並且您不能將原稿丟棄，直到完成，這意味着您將繼續增強原稿直到更換完成。兩倍的工作，沒有額外的價值。你可能會更好，保持應用程序並清理它。
你可能會考慮兩種思路，以幫助減少代碼庫的大小：在代碼
運行測試覆蓋率。通常人們使用它來驗證應用程序的功能，但如果您運行測試覆蓋範圍，並且只需長時間運行應用程序代碼，它就會告訴您哪些代碼不會被執行，因此可能會死機。如果系統混亂，它可能有很多死代碼，這是一個簡單的方法來找到候選人。有一些測試覆蓋工具可以以較低的開銷收集整個應用程序的數據;你可以在生產代碼中使用它們。
運行克隆檢測器。這會找到重複的代碼。奪標重複很容易刪除。一個好的克隆檢測器不僅可以找到相同的克隆，而且可以找到參數克隆，即已經複製/粘貼/編輯的代碼，但是可以用參數彙總。參數化克隆需要更多的技巧才能移除，但發現它們會告訴您可能錯過了抽象，並且刪除它們（通過替換對象或方法）將缺少的抽象插入到您的代碼中，從而使涉及該想法的進一步維護更加容易。 （這是不是一個非常衆所周知的事實，但克隆刪除也提出了測試覆蓋率，如果你真的使用測試覆蓋率驗證功能！）
購買「使用遺留代碼有效工作」一書。這是一個很好的開始。 –
@Benjamin Paap我有一天實際上給我的老闆發了一封郵件，詢問我們是否可以購買那本書。 :) –
「3500文件[...]他們所做的是令人印象深刻的，它是一個工作產品」 - 三分_against_完全重寫 - 不是一個淘汰標準，但... ... – VolkerK