中大型企業都會有代碼重構的需求。

技術類引起的重構。在實際的開發過程中，我們沒辦法過深的考慮問題，更不可能面面俱到，不得不承認，大部分的走業務線的公司，前期的項目基本是外包的，因為外包的費用要比養技術人員低很多，當然是個人外包，就是公司的老板或公司的同事，認識個程序員，或讓朋友介紹個程序員，讓他來把項目接過去，他可能再轉一手，這么做出來的項目，我之前的公司就是這么做的，綜合下來，這樣能更省錢。當然公司的主營業務不能是技術線，網站或系統只是打輔助，這是前提。走技術線的科技類公司最好找個技術合伙人，以技術為主，話語權很重要，否則中后期無窮無盡的麻煩。外包，意味著代碼質量沒法很好的監控，只要功能實現了，其它就無所謂了，而這樣導致的結果，后期要想把代碼接管過來，重新招人的話項目幾乎沒法去維護，有的時候，公司在融資后，往往會把這個外包的程序員接引公司來，讓他負責整個項目的研發。

產品業務引起的重構。不是所有的產品團隊都能很好的把握需求，更不要指望他們能有這種水平，公司里產品改需求真是太常見了，當然這并不全是產品的鍋，這其中就有相當一部分來自老板和客戶的需求變更，具體原因可以參考我的這篇文章《產品經理的興起，給開發帶來的革命是整個行業的進步還是倒退？

什么時候應該重構。比較理想的情況，是伴隨著你的整個項目的生命周期，不斷新的需求出來，加進新的功能，同時個人技術不斷的進步，對碼進行必要的重構，會為后面維護帶來相當大的便利，但，這僅僅是理想情況。實際情況中我們遇到的可能來自于公司層面的項目加急通知，項目的時間被大大壓縮，你很可能一直要么在寫新功能的路上，要么在改新需求的路上。重構，不產生新功能，資本不認可的，那不是他們關心的問題，即便重構工作可能會大大地降低整個公司的后期維護和開發成本，當然不重構，這些鍋還是開發來背，這就是技術有話語權的重要性。所以，互聯網公司還有另一種做法，寫的功能和代碼，只要能用就行，一來沒時間，二來重構的工作量不僅僅是開發，還有測試，還有各種隱藏的bug，尤其前人留下來的“不可觀望太久”的代碼，都是麻煩。