在五月的日常工作我碰到過這樣的困境：穩定系統Vs的更好的設計
「穩定系統Vs的更好的設計」
在日常的工作，當我固定的一些模塊，當我看到不好的設計
- >寫的不好代碼
- >寫的不好算法
- >優化可能
我寧願修復這些也伴隨着問題我正
但很多人反對我改變一些支持，誰反對人們會說
「如果系統穩定，你應該是商業導向的，如果你改變某些東西可能會導致迴歸，所以不要偏愛商業」
一段時間：
你會在6個月後看到自己編寫的代碼，你總是會看到在這個
一些改良效果的機會雖然誰支持會說：
這是持續改善和系統會更穩定
所以我想知道你們的想法
如果適用，編寫一個單元測試（或幾個，以涵蓋邊緣案例）。這讓你有信心重構並知道你沒有破壞任何東西。
當然，如果代碼是緊密耦合（或意大利麪條！），那將是一個問題。
如果看起來不完美，我的意見不是要修復舊代碼，除非它寫的方式正在干擾您目前的任務。
大部分代碼寫得不好。這是事實。如果你不是一個完美的團隊，對質量價值有完美的理解，並且對達到和保持質量水平的方法達成一致，那麼你的優化不會改變大局。你現在可以解決一些問題，但下一個人會再次弄糟這些東西。
如果它沒有損壞，請不要修復它 - 包裹它。儘可能多地隔離模塊，而無需更改其實施;如果出現真正的需求，他們應該接觸（固定，改進）。
我個人傾向於花費時間修理東西，而不是完成所需的任務。不幸的是，開始修復看起來像一個簡單的問題並解開一大堆混亂，然後希望你沒有做到這一點太容易了。
我也曾與相反的人合作過，只要能完成工作，他就可以與壞人一起生活。
通常情況下，您可以花費時間「正確地獲得某些東西」，以便將來更輕鬆地使用，並且您會發現代碼將來永遠不會被重用。
我認爲最主要的是要在團隊中平衡觀點，與他人定期討論事情並最終達到您項目的要求，因爲這是客戶支付賬單。
對你發現的任何問題都有建設性的意見 - 不要只是爲了它而挑選孔！隨着時間的推移，團隊代碼評審有助於改善不良代碼，因爲不好的代碼編寫人員會開始瞭解如何編寫好的代碼
我會建議用'TODO'評論標記錯誤的代碼，然後回來修復它以後的時間/預算允許。至少你已經爲潛在的問題領域提供了一面旗幟，而不必（可能）浪費時間去修復那些並不需要的修復。
如果您知道內部應用程序，或者具有全面的單元測試和時間以在非生產環境中測試應用程序，那就去做吧。否則，只在需要時才做。
兩者都是正確的，沒有簡單的出路。
如果您在遇到問題時沒有解決問題，則並非所有問題都會得到解決。
如果您修復的問題與您當前正在處理的問題不是100％相關，那麼人們會討厭你。另一方面，如果您修復了一些無辜的代碼（或者看起來無辜的代碼）並且以意想不到的方式破解，您會發現一些有價值的東西：脆弱的代碼。脆弱的代碼通常是沒有人敢碰的東西。但爲了讓你的產品更穩定，你必須擺脫這樣的代碼。這條道路的第一步是找到它。
我不得不承認，這樣的修復會在團隊中造成很多「不必要的」摩擦。當你觸摸脆弱的代碼時，人們會對你大叫，因爲他們害怕。通常，這些代碼會吹到你的客戶面前，所以你會從各種方向獲得熱量。
所以這取決於你想要造成多少痛苦以及你願意忍受什麼。如果您在遇到問題時修復所有問題，那麼到年底時代碼將會更好。但在一天結束的時候，情況往往更糟糕。
我想第二個所有的「如果沒壞，就不要修理它」的答案，但有一個相關的鏈接...
Things You Should Never Do, Part 1 - Joel Spolsky
本質 - 有時是不可理解的代碼實際上是一個你沒有機會理解的必要的錯誤修正。
一方面，改變已經或多或少工作的代碼會冒着破壞事情的風險，並且它很容易成爲一項非常耗時的工作。另一方面，由於維護不良代碼的負擔，另一方面，由於害怕破壞事物而使得單獨的代碼變得單調，可能會扼殺新的發展。
有時候代碼看起來很糟糕，因爲它必須處理複雜的角落案例，如Joel Spolsky points out，並且重寫它會因未能覆蓋這些角落案例而產生錯誤。有時候代碼看起來不好，因爲它確實很糟糕，重寫它可以修復你甚至不知道的錯誤。使用您的代碼庫的經驗應該可以幫助您確定哪些代碼是哪一個。
在傑夫莫澤Boy Scout Check-Ins討論「總是離開露營地比你發現它更乾淨」的想法。即使你無法修復所有的東西，也要始終保持代碼庫的清潔度，而不是你發現的那樣。隨着時間的推移，這些小小的改進加起
正如this answer所說，單元測試是一件好事。 Michael Feathers撰寫的Working Effectively with Legacy Code是關於這個主題的一個很好的資源。
同意你，最近我在一個模塊上工作，在我的工作模塊快500秒後，或者它比總時間少2分鐘，但它給了我很多的和平:)。並沒有迴歸.. – Satbir 2009-09-28 14:08:50
〜500毫秒 – Satbir 2009-09-28 14:09:36