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