我正在開發一個有點難以處理的系統。它99％沒有記錄，不遵循最佳實踐，並且相當難以理解（全局豐富，方法跨越50行，eval濫用等）。不幸的是，我對代碼庫相當陌生，並且需要添加功能。向需要重構的代碼庫添加功能
我確信那裏有代碼可以重複使用，但我必須要遵守最後期限，並且恐怕花費的時間最終會伴隨着我匆匆而過。從長遠來看什麼更好？我想部分想要儘可能重用，但另一部分則表示我應該專注於從頭開始編寫新功能，有重複的風險（當我有更多時間花費現有代碼時，計劃重構） ？我傾向於後者，但希望聽到一些意見。
謝謝！
http://www.joelonsoftware.com/articles/fog0000000069.html
http://discuss.joelonsoftware.com/default.asp?design.4.469415.13
http://www.joelonsoftware.com/articles/fog0000000007.html
http://www.paulgraham.com/hp.html
話雖這麼說，如果有小部分進行清理，這通常是罰款。一旦你對它進行了一段時間的研究，你就會更好地認識到戰略性本地化重寫將是最有效和最不危險的。
在生產代碼庫中，記住爲客戶保持現狀的狀態比讓新的東西出門更重要。它不會阻止你的老闆向你大喊大叫。但問問自己，有多少次因爲錯誤而轉換爲備用產品，而不是因爲你想要的增強速度在其他可行的產品中速度不夠快。
我會用你的直覺走：按照你知道的方式寫下來。 TDD，如果這是你的方法;無論如何都要儘量確保你的新東西測試涵蓋得相當好（當然，比現在有更少的混亂）。在路上，你可能確實有機會重構，找到重複的功能，並選擇保留哪些類的方法;很可能在這些情況下，你會發現你自己是守護者。
而且，當然，「在路上」永遠不會到來。至少你的新東西是工作的，可讀的，可重用的 - 這比你花時間追蹤現有代碼庫中的函數（如你所描述的）並重用它更好。
您所遇到的一切都可以通過閱讀工作Effectively With Legacy Code來克服。我知道你說你是在緊急的截止日期之內，但是急於並且沒有完全理解核心代碼庫可能（並且可能）有一些負面影響。
此外，你提到計劃一旦時間允許重構。我已經多次說過，讓我告訴你幾乎總是那樣的時刻永遠不會到來。第一次做對，併爲自己的下一個開發人員或後來添加新功能的人提供幫助。
感謝您的書籍推薦。我意識到「我會晚點再做」的態度是危險的，我認爲這是一個很大的原因，我不願意隨它去。 – 2010-07-13 01:39:41
我們在同一條船上工作：第一階段的工作方向很有效，但並不理想。第二階段改變了業務模式和邏輯.....這個階段是離岸的，如果公司真正理解了他們選擇構建的框架，這本身不會成爲問題。所以，在這裏我們試圖完成第3階段（消除第2階段的混亂，正確地使用框架），同時感嘆不得不編寫這樣一個寫得不好的代碼庫。有一些重大的挑戰 - 使用兩個JavaScript框架，笨重的傳統UI，垃圾代碼和對框架的重大更新，這使得我們的版本已經過時，幾乎不可能遷移到新版本。
以下是我們選擇要做的事情....它可能不適合您的情況。首先，我們的產品開發副總裁花了兩週的時間，完全考慮了數據庫結構。他重新安排我們的編程人員根據需要修改現有代碼，以適應正確，高效的數據庫結構。一旦完成了（痛苦的）步驟，我們就休息了兩週，以便在新功能上取得進展。然後，我從我的職責中休息一下，徹底重構UI，不使用一個Javascript框架，這樣我們就可以在一個共同的平臺上（一個概念，暗示可怕的離岸公司......）和製作有效地使用現代，高效的當前UI元素。我們將遵循80％-20％的任務組合，直到產品處於測試階段 - 80％達到最終要求，20％重構代碼並清理傳統混亂。每個員工都有一個他們負責「清理」或提高效率的領域。這些流程的文檔也是一項被授權的任務，並且是每位員工每週工作所需的百分比。
我認爲，我們的流程成功的關鍵在於即使在第三階段完成之前，第四階段也是關注的焦點。新代碼的構建具有最高的效率和可交換性，因此如果我們離開這個過時的平臺，則需要進行最少的更改。我正在嘗試一種劃分我們的流程（不僅僅是代碼）的方法，以便在時間合適的時候，理論上他們可以單獨移動到新的框架中。我們未來的計劃是在紙面上，隨着需求清單的發展和尋找最佳工具的研究正在進行。最重要的是，團隊領導是正確和有效地處理事務的堅持者，所以沒有任何現在或未來會走向前進，這是不正確的。
很難向管理層證明你需要往前走。當你的公司的整個未來依賴於一個停滯在測試階段的產品時，這更加困難。我將它與花費更多的燃油效率設備相比......現在它的成本會更高，但最終它將獲得巨大的經濟回報。我認爲在這種情況下取得成功的訣竅就是找到產品的中位數，當你花時間讓產品變得更好時，它可以「足夠好」地獨立站立。制定一個滿足中位數的戰略將挑戰業務部門的耐心，並最終在成功時讓你成爲英雄。制定一個強有力的計劃，傳達這個計劃，與他人一起好好玩，並讓你的尾巴脫穎而出。很快，你會再次享受生活！
不要擔心您添加的這一小部分功能。快速和骯髒。
如果您的團隊計劃對源代碼進行重構，請確保您擁有管理層的支持。讓您的管理層瞭解您現在面臨的問題：當前的代碼庫沒有遵循最佳實踐。應用程序變得越無結構化，添加功能所需的時間就越多。構建新功能不會花費大部分時間，但要確保它在各種情況下都能按預期行事，並且在出現問題時解決問題也會花費寶貴的時間。
如果你要重構應用程序，想想收益，你將不得不如果你會選一些現成的解決方案，以更好地實現應用程序的部分：
我可以繼續使用案例驗收測試上一段時間。 有時候，應用程序的完整重建只有兩步，但前進了四到五步。
是的，我已閱讀了重寫vs重構辯論...在這種情況下，雖然它不是一個真正的重寫。實際上，我正在添加功能，並且正在考慮是否應該花費大量時間尋找可以重複使用以避免重複的現有代碼......或者只是爲新功能編寫所有內容，並且在我的時間預算中感到舒適，然後重構稍後重複的代碼。沒有舊的代碼會被觸及。 – 2010-07-13 00:52:09
無需查看代碼庫，我可以提供的最好方法就是從舊代碼庫中學習。我喜歡第一篇文章，因爲它讓我想起修復bug的時間和精力耗費了多少時間。爲什麼這個或那個奇怪的情況在那裏？可能是因爲有人花了一個星期的時間找出了一個不明確的錯誤。除非需要，否則不要過度使用全局變量 - 有時遺留系統會充滿它們，因爲全局變量現在是「接口」的一部分。帶回了20歲的fortran 2個工作前的回憶。 :-) – eruciform 2010-07-13 00:55:20
我同意，我意識到有很多變數正在發生，它不是那麼枯燥，我想這就是我提出這個問題的原因。我想我可能會嘗試從兩個世界中獲得最好的結果 - 給自己多少時間來查找可重用的代碼，然後從那裏開始。 – 2010-07-13 01:29:03