重構是對**的簡化，無論是產品**還是測試**。重構不等於重新設計，只是簡化而已。重構過的**不會改變它的介面，只是更簡單。
我的**不見了
哈爾，初級開發人員
我現在參與的專案是離開學校後的第二個。在第乙個專案中，經理聽了我的**工作估算後說：「好，既然你還是個新人，咱們就再多加點兒時間吧，這樣你可以把學到的經驗應用到寫好的**中。」我覺得他這麼做純屬多餘，不過沒關係，我還是加倍努力，在截止日期來臨之時完成了手上的工作。接下來，我了解了整個系統真正的運轉方式，就得修改已完成的工作了，不只耗費了所有額外的時間，而且還多用了一點點。讓我感到驚訝的是：為了解決問題，我沒有編寫更多**，而是簡化了現有做法並去掉一些**。我的**不見了。
現在這個專案，我使用了持續整合，而且一邊開發一邊重構。在開發時，簡化並清潔**，而不是改變設計，這讓我對自己手上的工作和開發速度有了更清晰的認識。而且，我的**仍然在繼續消失。
如果你曾經隨專案進展計算過**行數，要是專案採取順序式生命週期，或是將整合和測試放在專案臨近結束時進行，那就會看到乙個s形曲線（見圖9.1）。可以注意到，開始整合和測試後，**的數量就開始減少了，這是因為發生了重構。（沒錯，也許是重新設計了某些東西，不過以我的經驗，主要是重構造成的。）如果不準備在專案快結束時進行重構，或是不願意在順序式生命週期中償還技術債務，**量會居高不下。在專案快結束時，**縮減就不會發生。
圖9.1順序式生命週期中**量的典型變化
在使用敏捷生命週期的專案中，**量的曲線很可能如圖9.2所示。**的增長要慢得多，因為開發人員僅僅編寫當前功能需要的**。他們還會一邊開發一邊重構，而不是等到專案快結束時再去修復一大堆bug。（對於很多bug來說，去掉某些**就可以解決。）
圖9.2敏捷生命週期中**量的典型變化
專案經理可以讓重構與開發同時進行，也可以最後再進行重構。如果希望發布的產品中缺陷越少越好，就必須要對**進行重構。如果讓重構與開發同時進行，重構的成本是非常小的。如果打算在專案結束時重構，那成本可就高了，而且你會發現總是沒有時間去做重構。要麼管理層就會指示你不要重構。高昂的成本**於開發人員得到的反饋延遲過久，以及不知道應該重構哪些**以及如何重構，因為開發人員很久沒有思考過要重構的**了。
多幾隻眼睛盯著產品 保持專案節奏實踐之四
邀請團隊成員相互複查工作。複查的形式並不重要，結對程式設計 pair programming 夥伴複查 buddy review 同行複查 peer review 走查 walk through 正式 檢查 formal code inspection 都可以。複查能夠為專案方方面面帶來好處。專案經...
分離需求與GUI設計 保持專案節奏實踐之七
我們希望系統解決的問題通過需求得以體現。gui設計是要體現出gui如何引導使用者使用系統以解決他們的問題。很多專案都將gui設計混同於需求的假面之下，這很讓人訝異。如果你的專案總是陷於無盡的需求工作之中，看看問題是不是出在gui設計上。gui是設計，不是需求 凱倫，程式經理 我在一家新公司工作時，試...
持續整合 保持專案節奏實踐之一
專案經理不但要用管理實踐掌控專案，還可以歡迎團隊改變自己的技術實踐，從而獲得更大收益。本章包含的一系列實踐，能為專案帶來很多好處。專案經理和團隊要根據自身的實際情況，判斷如何調整 使用這些實踐，而不要強制推行。如果你認為它們有所裨益，不妨將其介紹給團隊，並歡迎團隊積極嘗試。9.1 在專案中使用持續整...