我靠tdd和重構，而且我從來不怕重構的時候改太多。首先有tdd你就知道改動會不會出問題。其次改掛了回不去大不了revert重新來。 寫程式千萬不要讓需求無中生有。那些甲方還沒提的，或者你還沒做到那裡的，那個需求暫時就等於不存在。千萬不要為了將來的變化去在架構上留太多東西。反正你有tdd，架構不滿足要求了重構就是。想要在架構上留下靈活的空間的話，你就留下那些100%會發生的就行，千萬不要想以後可能會怎麼怎麼樣。可能就是不可能，萬一發生了，你有tdd，重構就是了。 最後不知道怎麼tdd，不知道重構改了介面怎麼繼續tdd的，推薦xunit test patterns，別看中文版，翻譯成屎了。 我自己的心得是，如果一個重構要改介面，你就先改介面但不要重構改實現，儘可能少改程式碼（實踐上通常是複製程式碼）讓你的介面的變化帶領著單元測試一起變動，保證正確性。這個時候程式碼可能變得很難看，沒關係測試先過了先push，接下來再在不動介面和測試的前提下把被搞亂了的實現搞好。 以前最驚心動魄的，是一個十幾萬行的程式，我把string和list重新設計了，帶來了太多編譯錯誤，vc++編譯了一半告訴我錯誤太多罷工了。不過反正我有耐心，慢慢就全部重構完了。這就是寫程式的日常。有tdd，一個commit改幾千行程式碼，內心穩的一筆。
我靠tdd和重構，而且我從來不怕重構的時候改太多。首先有tdd你就知道改動會不會出問題。其次改掛了回不去大不了revert重新來。 寫程式千萬不要讓需求無中生有。那些甲方還沒提的，或者你還沒做到那裡的，那個需求暫時就等於不存在。千萬不要為了將來的變化去在架構上留太多東西。反正你有tdd，架構不滿足要求了重構就是。想要在架構上留下靈活的空間的話，你就留下那些100%會發生的就行，千萬不要想以後可能會怎麼怎麼樣。可能就是不可能，萬一發生了，你有tdd，重構就是了。 最後不知道怎麼tdd，不知道重構改了介面怎麼繼續tdd的，推薦xunit test patterns，別看中文版，翻譯成屎了。 我自己的心得是，如果一個重構要改介面，你就先改介面但不要重構改實現，儘可能少改程式碼（實踐上通常是複製程式碼）讓你的介面的變化帶領著單元測試一起變動，保證正確性。這個時候程式碼可能變得很難看，沒關係測試先過了先push，接下來再在不動介面和測試的前提下把被搞亂了的實現搞好。 以前最驚心動魄的，是一個十幾萬行的程式，我把string和list重新設計了，帶來了太多編譯錯誤，vc++編譯了一半告訴我錯誤太多罷工了。不過反正我有耐心，慢慢就全部重構完了。這就是寫程式的日常。有tdd，一個commit改幾千行程式碼，內心穩的一筆。