這是一個非常好的問題，作為一名從業多年的程式設計師，我來回答一下這個問題。

首先，對於一款已經發布的軟體產品來說，在很多情況下，重寫程式碼並不是一個明智的選擇，一方面重新程式碼對於技術人員來說，未必會帶來技術上的提升，另一方面重新程式碼可能會導致大量新的問題出現，結果未必像之前想象的那樣好。

對於不少開發團隊來說，在決定重寫程式碼的時候，往往有三方面因素，其一是開發團隊的人員變動，這是比較常見的一個原因，而且很多新接手程式碼的程式設計師通常也比較支援重寫程式碼，原因自然是不想閱讀已有的程式碼邏輯；其二是產品在升級迭代的過程中遇到了較大的障礙；其三是技術體系的重大變革。

在這三個因素當中，除了技術體系的變革不得不進行程式碼重寫之外，其餘兩種情況一定要慎重。實際上，當技術體系出現重大革新的時候，產品往往也會基於新的技術模式進行重新設計，這與重寫程式碼還是具有一定區別的，程式設計師在這個過程中也會獲得明顯的技術提升。

按照歷史經驗來看，如果在開發團隊出現人員更替的時候，重寫程式碼往往會帶來更多的問題，不僅會延長開發週期，同時也會出現很多溝通上的問題，之前已經解決的問題往往還需要再解決一遍。對於已經上線的網際網路產品來說，重寫程式碼可能會帶來比較嚴重的安全問題，這一點一定要引起足夠的重視。

最後，對於程式設計師來說，透過修改自己的已有程式碼，或者團隊做定期的review是很有意義的，但是要大面積重寫程式碼一定要慎重，尤其是重寫其他人的程式碼，更應該慎重。

重寫程式碼是需要很大勇氣的。

如果需要重寫的程式碼是經過了許多人轉手的，那麼恭喜你，你掉進了一個大坑。不同程式設計師的程式碼風格、程式碼註釋、文件，這些都將成為你重構路上的絆腳石。而且更常見的是許多程式設計師壓根不寫文件、註釋，畢竟這些都是程式設計師最討厭的事兒。

就算你比較厲害，透過程式碼反推邏輯，但是如果程式碼中本身就有坑，可能後面就會被越冷越深了。這種經過多次轉手的程式碼，大機率很難找到人解釋的清真正的程式碼邏輯吧。沒有準確的業務邏輯，也沒有清晰的程式碼邏輯，重構之路何其難哦。

就算裡面有註釋，但是要去翻看各種風格程式設計師的程式碼，也是一項巨大的挑戰。大括號風格、換行風格、程式碼臃腫，這些都是不好啃的硬骨頭。這樣重構下來，估計自己都要掉不少頭髮…

還有一種情況就是重寫的是自己之前的程式碼，有註釋的習慣還算好一些，如果沒有可能真的看不懂自己曾經寫的程式碼，也就很難看得懂程式碼的邏輯了。

總之，對於經過多次轉手的程式碼，重構難度還是不小的，特別是那種邏輯有些繞的，更是難上加難。

程式碼初寫一時爽，待到重構天天愁！

也不是絕對的不能重寫程式碼，任何事情都要去評估收益風險比，如果你重寫之後可以獲得更好的可讀性，更高的效能，也是可以重寫的。

比如淘寶為了去ioe重寫了整套的背後的系統，然後他達到的收益是他去掉了IBM小型機 oracle資料庫和Emc儲存裝置，為阿里節省了鉅額的成本。

很多公司都有一些歷史悠久程式碼，但是沒有重寫，是因為他重寫之後的收益並不高。但是可能影響核心業務，這樣如果出現問題，就得不償失了。

從事程式設計開發多年已經有一種共識，不好的程式程式碼就是想盡辦法進行重構，優秀的程式設計師整天做的事情是整天考慮著重寫程式碼，優秀的程式碼是經過無數次的洗禮出來的，一次性就寫出高質量的機率不是很高，而且程式碼的重構不僅僅是程式碼的問題，關鍵是實現方式上的差異。現在大家對於開源的認識越來越多了，開源精神的宗旨是鍛造出最極致的程式碼框架，所以無論是linux核心社群還是谷歌旗下幾個主流的開源社群，每天的程式碼更新量都會非常巨大，無論什麼模組都力求做到最極致。

當然開源社群的思想和實際企業中追求的目標有些差異，開源屬於完全自由的思想，追求程式碼的極致實現方式，企業就要考慮實際的生存現狀，企業從大方向上也是趨向於走向理想化，但現實中企業首先要保證有收益才會生存下去，所以企業的生存發展過程中是不斷向著理想化的狀態邁進，很多企業還沒開始進入理想化的狀態就已經倒閉了。所以程式設計師的理想化狀態要符合當前的工作實際狀態。

這點就講到了開源社群的起源，首先開源社群的發起者屬於理想主義者，而且基本上算是衣食無憂的狀態，吸引著一群同樣狀態的人去維護，更新維護程式碼的標準都一致，大家一起維護這套程式碼，不斷重寫程式碼重構程式碼以達到理想的狀態。對於一個標準的程式設計師講基本的職業素質講見到不合適的程式碼就是選擇重構，但平時企業工作的工作安排很少直接安排程式碼重構，都是以任務板塊的方式估算時間，所以重構的時間只能放在業餘的時間。

但在實際開發過程中重構程式碼的難度還是非常大，如果接手是一團亂糟糟的程式碼，而且專案週期卡的非常緊迫，明知道程式碼裡面很多坑但沒時間去重構，遇到這種狀態想要長久的安穩呆下去還是要想盡一切辦法重寫如果實在不行進行程式碼的最佳化，程式設計師的準則就是寫出優秀的程式碼，並且持續不斷的最佳化，寫出讓自己看著順眼程式碼。