(Regression)。這時，重構會起到與其初衷相反的作用。所以我們應該盡可能多地增加單元測試。有些老產品，舊代碼，可能沒有或者沒有那么多的單元測試。但我們至少要在重構前，增加對要重構部分代碼的單元測試?；谥貥嬆康牡膯卧獪y試，應該遵循以下的原則(見《重構》第4章：構筑測試體系)：
- 編寫未臻完善的測試并實際運行，好過對完美測試的無盡等待。測試應該是一種風險驅動行為，所以不要去測試那些僅僅讀寫一個值域的訪問函數(shù)，應為它們太簡單了，不大可能出錯。
- 考慮可能出錯的邊界條件，把測試火力集中在哪兒。扮演“程序公敵”，縱容你心智中比較促狹的那一部分，積極思考如何破壞代碼。
- 當事情被公認應該會出錯時，別忘了檢查是否有異常如期被拋出。
- 不要因為“測試無法捕捉所有Bug”，就不撰寫測試代碼，因為測試的確可以捕捉到大多數(shù)Bug。
- “花合理時間抓出大多數(shù)Bug”要好過“窮盡一生抓出所有Bug”。因為當測試數(shù)量達到一定程度之后，測試效益就會呈現(xiàn)遞減態(tài)勢，而非持續(xù)遞增。
說到《重構》這本書，其實在每個重構方法中都有“作法(Mechanics)”一段，在重構的實踐中按照上面所述的步驟進行是比較穩(wěn)妥的，同時也能避免很多不經意間制造的回退出現(xiàn)。
4. 要求提交代碼前做Code Review，而開發(fā)人員不做，或敷衍了事，怎么辦?
如果每個開發(fā)人員都是積極主動的，Code Review的作用能落到實處。但如果不是呢?團隊管理者需要一些手段促使其有效地進行Code Review。首先，我們采用的Code Review有2種形式，一是Over-the-shoulder，也就是2個人座在一起，一個人講，另一個人審查。二是用工具Code Collaborator來進行。無論哪種形式，在提交代碼時，必須注明關于審查的信息，比如：審查者(Reviewer)的名字或審查號(Review ID，Code Collaborator自動生成)，每天由一名專職人員來檢查Checklist中的每一條，看是否有人漏寫這些信息，如果發(fā)現(xiàn)會提醒提交的人補上。另外，某段提交的代碼出問題，提交者和審查者都要一起來解決出現(xiàn)的問題，以最大限度避免審查過程敷衍了事。
博主Inovy在某個評論說的很形象：“木(沒)有賞罰的制度，就是帶到廁所的報紙，看完就可以用來擦屁股了?！睕]有獎懲制度作保證，當然上面的要求沒有什么效力。所以，當有人經常不審查就提交，或審查時不負責任，它的績效評定就會因此低一點，而績效的評分是跟每年工資漲落掛鉤的。說白了，可能某個人會因為多次被查出沒有做Code Review就提交代碼，而到年底加薪時比別人少漲500塊錢。
5. 軟件研發(fā)到底需不需要文檔?
軟件研發(fā)需要文檔的起原可能有2種，一是比較原始的，需要文檔是為了當開發(fā)人員離職后，企業(yè)需要接手的人能根據(jù)文檔了解他所接手的代碼或模塊的設計。二是較高層次的，企業(yè)遵從ISO9001質量管理體系或CMMI。
對于第一種，根源可能來自于兩個方面：
- 原開發(fā)人員設計編碼水平不高，其代碼可讀性較差。
- 設計思想和代碼只有一個人了解，此人一旦離職，無人知道其細節(jié)。
在編碼前寫一些簡單的設計文檔，有助于理清思路，尤其是輔以一些UML圖，在交流時也是有好處的。但同時，我們也應該提高開發(fā)人員的編碼水平增加其代碼的可讀性，比如增強其變量命名的可讀性、用一些被大家所了解的設計模式來替代按自己某些獨特思路編寫的代碼、增加和改進注釋等等，以減少不必要的文檔。另外推行代碼的集體所有權(Collective Ownership)，避免某些代碼只被一個人了