本文授權轉載，作者：非著名程序員（公眾號：smart_android）

其實過完年回來，我們的項目也一直在強調重構，在實踐重構中，但是到目前為止，基本沒啥進度。關于項目的重構，我說：基本上大部分都是騙人的。你們信不信？那你可能會問：為什么一開始不把代碼寫的更好一些，邏輯更嚴密一些呢？那歡迎大家看我寫的這篇文章《代碼質量差，bug多？我們都是被逼的 》，看完你會深有同感的。

關于項目重構的問題，為什么一直做不完呢？直到我在瀏覽微博時，看到了一個非常好玩的對話，可謂是：感同身受，深有同感。知道真相的我，眼淚都快笑出來了，估計看到下面的對話，你們也會感同身受的，身臨其境都有可能。對話如下：

A：重構80%都會失敗，因為業務線的需求永遠都不會停，資源有限，所以不花大代價，輕易不重構，寧可開發的慢一點，寫好。B：其實以業界大部分產品經理的水平99%的項目都活不到重構的那天，所以業務量上來再重構更省資源。對話內容來自于@Easy的微博

看到第一句話A說的，一看就是深受其害的程序員說的，是不是說到你心坎里了。中招的同學請舉手，作為我們有責任的程序員只能仰天長嘯：有心寫碼，無力高效。bug其多，痛哉痛哉！下次你們老板和產品經理再催你趕進度，你就大喊：時間不夠，代碼瞎湊，毀了軟件，完了項目。上線以后，如果用戶體驗不好，老板來找你談話或者訓你，你就說：這個鍋我們程序員不背。B說的話，眼光很長遠，要這么說的話，確實更省資源。要是產品經理和老板看到的話，估計不開森了。

其實項目重構是一個非常鍛煉程序員能力的活，而且重構是一個不斷優化和學習的過程。項目重構的重要性更不用說了，通過調整程序代碼改善軟件的質量、性能，使其程序的設計模式和架構更趨合理，提高軟件的擴展性和維護性。可能你會問：為什么不一開始就把項目做好，代碼質量寫的更好呢？話雖說可能是時間問題引起的代碼質量差，程序員為了趕工期，但是即使是給程序員充足的時間，他也不可能預見未來的需求的變化， 可擴展性和可維護性就無從談起，今天你想好了代碼這些，明天估計需求就又變化了。所以一個持久的好的項目也不可能避免重構的發生，寫代碼的高手和大神也一樣，都得經歷這個階段。

那何時才能觸發重構呢？答案其實很簡單，你是在忍受不了混亂的代碼的時候或者感覺可讀性很差的時候。你的忍耐力決定重構的時機。當然如果你寫的程序一直在崩潰的話，估計你得被迫去重構和優化了。其實代碼重構的出發條件應該是一下幾點：

• 牽一發而動全身的修改

• 代碼中存在過多的重復代碼

• 過渡的耦合

• 過長的方法和類（過長的代碼，邏輯復雜，bug可能幾率上升）

• 太多代碼無注釋，你已看不明白

如果中了上述幾條，你該想想代碼重構了。不要被動的去重構，主動去重構還是非常有必要的，可以避免很多問題的發生。

代碼重構其實最重要，最應該注意的兩點，也是應該達到的目的就是：代碼的簡潔，邏輯嚴密和性能的優化。這就是重構的意義所在和內涵。

寫到這里，你們可能會問我：那該如何重構呢？是啊，我一本正經的寫了這么多，你們肯定想知道這個問題的答案，到底該如何重構？那我就一本正經的告訴你們答案：如果老板和產品經理不好好對待程序員，你們基本到不了項目重構的那一天。A和B說的就是真理，你們服不服？

如果不服的話，我怕你們打我，我還是再一本正經的說兩句吧，如何重構：在不改變軟件系統外部行為的前提下，改善它的內部結構即可。也可以借助工具完成，重構工具能夠修改代碼同時修改所有引用該代碼的地方。

請大家把這篇文章轉發到朋友圈，讓你們的老板和產品經理看看吧，讓他們認識到問題的嚴重性，給自己爭取更多的開發時間。下次如果產品經理再催你們進度，你們一定要記著一起大喊：時間不夠，代碼瞎湊，毀了軟件，完了項目。

轉載于:https://www.cnblogs.com/Amoyios/p/5764392.html

總結

以上是生活随笔為你收集整理的关于项目重构，知道真相的程序员眼泪笑了出来的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。