何興才
【國內程序員很少進行代碼重構】，這個現象雖然沒有什麼調查統計，不過我寫了十多年代碼，也發現身邊的程序員大多數是這樣的，【寧可寫新的代碼，也不願意重構老代碼】。下面我也談談自己的看法：
系統沒有問題，就是最大的功勞
我見過的大部分的傳統行業的軟件公司或IT部門是這樣的（互聯網公司不太瞭解），“只要系統穩定，那麼就是最大的功勞”，而保持系統穩定最好的方法是什麼？就是儘可能的不要動系統！
可能很多人不能理解，但很多公司確實是這樣，甚至公司對項目的考核標準中，項目有什麼突破的權重很低，是否有生產事故的權重很高。所以很多“機智”的項目組成員，千方百計的不接需求，或者把需求推給別的項目組。在這種單位裡面，別說重構了，新代碼都寫的不多。
測試覆蓋度太低，重構代碼沒辦法保證質量
代碼重構，很重要的一個問題：“重構後的代碼誰來保證？如果影響到原有的功能怎麼辦？”
這時候很有效的一個方法，是使用各種自動化的測試來保證重構代碼的質量。
但是，大部分公司，不管是單元測試還是其他的自動化測試，都是不健全的，甚至是沒有的。所以只要不是被逼不得已，程序員寧可重新寫一個方法，也不願意重構之前的代碼。
其他
代碼風格有差異，看別人的代碼真心累。
有的代碼寫的真心不敢恭維，各種奇怪的思路真的理解不了。
文檔沒有，註釋也沒有，有時候看代碼只能靠猜。
希望我的回答，能夠幫助到你！我將持續分享Java開發、架構設計、職業發展等方面的見解，希望能得到你的關注；另外，關注我後私信【資料】兩個字，可獲取架構、大數據、面試等相關資料。
會點代碼的大叔
Time is money. 以目前國內互聯網的情況，需求應接不暇，程序員基本上都是被需求與業務趕著走，時間非常緊張，在這種情況下，程序員很多時候唯一的選擇就是趕緊實現需求的功能。所以，一個項目下來，代碼基本上都變得非常非常的“垃圾”。
也有很多程序員想過在項目結尾的時候進行代碼的重構，基本上每個程序員也都知道重構代碼的好處，但是並不代表著真正能做起來。還是那個原因，國內互聯網的速度太快，需求應接不暇，做為程序員，基本上沒有時間來做這件事情。
而另外一個原因是跟團隊負責人有關。若團隊負責人能夠意識到重構的好處，那麼他可以為此單獨劃分一段開發時間出來，讓大家分別負責一個模塊進行重構，這都是可以安排做起來的。這也需要團隊負責人如何在需求人員的需求與代碼質量的進度上做一個平衡，進行統籌安排。
最後我想說一個可能很少意識到的原因，那就是人員流動問題。國內互聯網目前人員流動非常的大，尤其是北上深這樣的互聯網發達的城市，基本上是平均兩年就會走一大波人，在這樣的情況下，也會考驗從業人員的職業道德，即我到底要把代碼寫的多好，要把代碼的可維護性做到多好，其實這都是從業人員自身需要考驗的問題，因為完成一個功能很容易，但是要考慮的全面就是另外一回事了。而人員流動帶來的另一個問題就是有一些代碼是很難看懂的，即有些代碼在人員離開後成為了“歷史”，無人敢動。這也會阻礙著軟件的重構工作的進行。
從我所講的這幾種情況來看，重構其實是大家都能知道的好處，但是真正實施起來卻又有現實的約束，需要負責人來做這樣的統籌安排與推動。
藍色Zero
說到代碼的重構對於國外的程序員提到的比較多，特別是大型的開源工程，基本上一個模塊或者函數的實現會反覆的修改，一個文件能被修改成千上萬次，曾經訂閱了linux內核組的郵件，每天的收到的修改文件成千上萬，有時候一個文件都能被修改上百次，對於文件修改最瘋狂的是google的chrome源碼，重構的次數，讓你覺得每天都在重寫但是功能上感覺越來越流暢。為什麼我們周圍的程序員絕大部分時間做的不是這樣的事情。
為啥從直覺上覺得老外的寫的代買質量比我們的要高，我們國內的程序員絕大部分的時間是在趕進度，準確的來講忙著增加功能和修改bug，其實也從側面反映出為什麼國內出不了android以及Linux等影響深遠的科技創新，從全球開源代碼的佔比就可以看出，差距還是很巨大的。
為什麼覺得老外寫的代碼比我們的強？
1.國內軟件發展主要階段還在解決有沒有，還遠談不上強大
中國的軟件經過近幾十年長足的發展，已經取得了巨大的成就，特別在互聯網行業已經有幾個巨頭躋身世界前列了，最近炒的很熱的臉書的用戶數據洩密事件，作為當事人扎克伯格，也在論述中提到中國有幾個很厲害的互聯網公司，這說明中國在互聯網領域還是取得了相當大的成就，但是在一些核心的領域，或者門檻很高的領域差別還是非常巨大。
任何事情在發展的初級階段首要考慮的是不是有沒有，所以如同創業初期的公司會選擇短時間內搞出來個產品，哪怕是不成熟的產品，然後快速的投入市場，根據市場用戶的反應同步追蹤問題，等到產品差不多穩定，並且產品在市場上有了一席之地之後，後續的事情就要考慮優化功能，對裡面的代碼或者產品的性能進行全方面的提升，目前國內大部分的互聯網一般比較年輕，還在解決有沒有的問題，相信隨著時間的推移以及國內軟件的發展，也會有大量的高質量的開源框架代碼出來，但這一切都需要很長的時間。
所以國內的程序員大部分時間都是在趕進度和根據需求完成功能代碼。
2.軟件產業的底子還很薄弱，歷史積澱還不夠
舉個很典型的例子，現在很多國內的程序員到了30多歲就開始考慮後續的轉型了，因為後面的輕輕人會帶來很大的衝擊，所以大部分的30多歲的程序員都在考慮自己後路，都要考慮轉型的問題。老的有經驗的程序員反而轉型去做管理或者合夥創業了，哪有幾個還在安心搞技術，年齡大了還在搞技術的還被人鄙視，覺得自己沒有出息。
但是在國外寫代碼是一種很常見的職業，和別的工種沒有多大的差異，40，50歲了寫代碼也是比比皆是，做軟件是一種技術工種，經驗的佔比是很高的，所以老程序員寫出來的代碼更加有深度，穩定性更高，一切的根源還是產業的發展不夠成熟，需要時間和歷史的積澱，從這方面講國內的軟件整體產業還是比較薄弱，從業人員的整體素質和工作氛圍還有待慢慢的成熟，周圍都是有經驗的程序員在帶領著如何去重構代碼，如何提升代碼的質量，而國內大部分的程序要還是被產品經理鞭策著增加需求和修改代碼。
3.公司的文化差異
目前很多的中國技術公司更多的追求的是短期利益的最大化，在基礎軟件的投入遠遠不夠，畢竟基礎的投入很難短期見成效，在一個具體的場景，有一個產品主體的功能已經實現了，也能在用戶那邊投入使用了，一般的公司很難拿出時間來，讓你做代碼的重構，畢竟這種事情很難直接產生經濟效益。這與公司本身的文化差異有很大的關係，重視的技術或者懂得技術的公司對於這方面相對比較重視，反之就差很多。
小時候課本上就說著我們落後100年，所以高樓大廈不是一天建成的，所以在追趕的道路很漫長，所以承認存在差距，然後努力加倍的去追趕。
大學生編程指南
謝謝樓主的問題，這是一個我特別想回答的問題？
為什麼？因為，第一，我是一個對代碼有潔癖的人，受不了一坨，一坨那樣的代碼。第二，我是一個踐行Clean Code 的人，給大家我主要負責的一個項目的一組數據（JAVA），總代碼量20萬行,UT coverage(單元測試代碼覆蓋率）82%，代碼重複率0.5%，代碼規則(sonar）違反（Code issue）0,甚至連最低的違反都沒有。
也正是因為我的項目在實踐Clean Code上的數據，我經常去給不同的團隊做分享，也對團隊對這個重構不太上心有一些理解。
大致以下幾個原因。
第一，也是最多的，交付壓力，大部分人都會抱怨，你看我們有這麼多新功能，還有那麼多bug,根本忙不過來，哪有時間重構？
第二，重構意識不足，老闆，管理人員總是希望這個我們要有，那個我們也要實現？為什麼？因為別人有，別人有我們沒有可能會造成用戶流逝。即使有一些有見識的程序員和老闆反應這個重構問題，但是重構從來不是高優先級的。畢竟，現在的軟件的生命週期可能很短。
第三，人員流動性大，這個是我聽過最奇葩的一個理由，我問一個來聽培訓的哥們，說你代碼寫成這樣，以後怎麼維護？這個哥們說，我也知道難維護，但我明年就跳槽了。
第四，設計上就不需要重構，曾經給一個保險公司做分享，我本人也是做金融相關產品後臺的，我就問你們這樣寫代碼，可能三四年以後就非常難維護了，還是要儘快重構。他們的回答是，我們不重構，我們只重寫。什麼意思那？就是一個系統，三四年以後在寫一遍。
第五，程序員本身的問題，可能第一寫單元測試，修改命名，修改代碼結構，是一件很沒有成就感的事情，也是一個沒有多少附加值的事情。畢竟現在你去找工作，這個代碼質量方面的問題會問得很少。
第六，我見過的我不能反駁的一個回答，我的英文太差，不能很好的命名，而我也不想學英文。
第七，反正我已經實現了功能。
最後，用一句話來提醒程序員們，重構是多麼重要。
出來混遲早要還的，挖了坑遲早要填的。
楊興華
不重構是不可能的，或多或少吧。說很少準確一點，這麼說吧，功能都做不完，還重構？！而且系統涉及到方方面面，你對項目的整體瞭解程度決定你能重構的深度，團隊開發中沒問題的代碼你重構了之後如果問題一堆，誰來負責。。。耽誤了後續工作責任誰來承擔，這些都是要考慮的成本，換句話說重構有可能是好心辦了壞事，而有幾個領導會關心你架構有多牛逼，代碼多優雅？他們看結果，不是過程。除非是遇到項目進行不下去，一般不會輕易做大的變動，不過那個時候基本上可以叫重做了。。。當然大公司對代碼方面的要求比較嚴謹，而且有資源對架構和代碼質量提供保證，小公司嘛，奔著項目去做的，能按時完成任務都已經累到夠嗆了，也就像你說的很少考慮重構了，但一定不是沒有。😂
總有刁民佔暱稱
進行代碼重構不是一件容易的事情，務必需要對需求熟悉；對代碼歷史變更熟悉；對代碼框架，模塊熟悉；對產品更新迭代做好風險把控，時間成本把控……
進行代碼重構需要能力非常高，責任心非常強的人進行，甚至需要一個優秀的團隊完成。
為什麼要代碼重構？理由一大堆，小編認為主要有兩條，一是原代碼已不適合擴展新需求，二是原代碼已擁腫不堪，亂七八糟。
為什麼很少重構？除了上述分析外，還有其他因素，如人員流動快，原團隊原作者早已不知何去何從了。又如需求和業務繁多，完成工作開發都累得半死不活，日理萬機似的，哪有時間和心情重構？
謝謝大家。
宏思微想
1.國內程序員技術能力不足以進行代碼重構
大量的軟件從業人員連編程規範都不熟悉，怎麼可能做代碼重構？更多的人只會寫寫hello world，只會拷貝粘貼小段代碼，連if else這種語句都寫不清楚甚至漏掉邏輯，連面向對象的編程思想都沒有，談何重構？
2.國內程序員的溝通能力說服能力一般。
進行軟件重構，必須說服經理，讓經理相信重構會帶來軟件質量的提高和故障率的逐步降低，這樣經理才會安排人力進行重構。
3.國內軟件開發更注重bug的及時解決
國內軟件開發大量的人力被分配到解決短期的某個bug，沒人抽時間思考如何長久的徹底的解決軟件缺陷，其實解決bug不重要，找到軟件的缺陷或者性能低下的地方才重要，這些才是重構的點。國內加班加點疲於奔命式的開發，沒人考慮bug率是否長期內能夠收斂，總是先解決眼前的問題再說，處於一個永遠解決bug的死循環裡。
這種工作模式是愚蠢的，不是smart的。
軟件開發，一定要動腦子，不要蠻幹，這不是耕地，力氣大就耕的多。
重構代碼的目的說白了，就是讓軟件開發人員更自由。
明史林泉
呵呵，
老大說：
你趕緊去修復一下這個bug，
還有幾個功能沒有實現，加班搞一下，
pm 說：
這個功能改一下，
還有這個，界面重新調整一下，
這個業務流，現在不一樣了，
客戶需求需要多幾個功能，
老闆說：
這東西下週能出來嗎？
FMsunyh
現實是要麼亂重構，要麼不重構。好的重構是建立在已有的經驗和教訓上了，為了徹底的解決一些頑疾，或是為了更好的設計去迎接新的發展而發生的。而所謂亂重構往往是團隊換人，對以前的產品和代碼不甚瞭解，又不願意去學習，乾脆推倒重來的做法。這種重來非常危險，談不上任何改進，該踩的雷又踩一遍，只是為了自己維護方便。也許這種本身就不該叫做重構，應該叫做重來。回到題主的問題，很少進行重構的主要原因是沒有技術上的追求。其原因要從以下幾方面來談。第一是公司沒有追求，過度追求結果第一，在這種指導思想下，所有人都願意做開創者，而不是鞏固維繫者，很簡單，做新東西容易出成績。第二是國內的公司普遍不重視技術，或者對技術有偏見，外行指導內行情況很普遍，所以不可能有什麼重構。第三是技術人員自我追求不夠，不求甚解，得過且過。
Shooray
為啥要重構。互聯網時代，產品更新換代快。如果不是很好的框架，經過幾次升級後，如果要滿足產品升級的真心不如重新動工搞一遍。windows linux office這些固定功能的產品能談談重構代碼。但是比如有些公司，開始是做p2p的，沒多久就換成小額貸款了，過了幾天又換成消費分期了。連底層數據都要經常變動。重構，那是不存在的。拋開業務談代碼和技術都是外行
