我和充斥臭味代碼的戰(zhàn)爭
by leetaolion 2008-01-12
從去年8月份到現(xiàn)在，我一直在從事一個(gè)261k行代碼的項(xiàng)目（不含空行和注釋）。
其中由我本人編寫的代碼10.9k行（不含空行和注釋，我本人所寫的注釋大約1/8有效代碼行，屬于比較少的）。
其他模塊注釋非常少，只在接口文件聲明虛接口的時(shí)候會(huì)有一行注釋，實(shí)現(xiàn)文件中幾乎沒有注釋，大部分文件連文件頭都沒有。
在我加入小組之前，小組是穩(wěn)定的，每人負(fù)責(zé)幾個(gè)模塊，不采用TDD，依靠的是每日集成。每日的目標(biāo)是：可以Build的代碼。
我加入之后，起初做些邊邊角角的工作。這樣的日子大概持續(xù)了1個(gè)半月的樣子。然后在一個(gè)午睡并沒有完全醒來的狀態(tài)下，接手了一個(gè)核心模塊DataMgr_Module，這個(gè)模塊管理所有的計(jì)算的輸出結(jié)果。
一開始對(duì)工作的估計(jì)過于樂觀，認(rèn)為1個(gè)月就可以搞定。接手之后才發(fā)現(xiàn)，原來的DataMgr_Module其實(shí)是兩個(gè)module，小組的老大和另外一位同事對(duì)于DataMgr是各自為政，每個(gè)人都有一份自己的數(shù)據(jù)結(jié)構(gòu)和管理方法。由于同事同時(shí)負(fù)責(zé)多個(gè)上層模塊的開發(fā)，所以，DataMgr_Module和上層完全耦合在一起，DataMgr_Module的大部分功能都分布在各個(gè)上層模塊之中，每個(gè)上層模塊重復(fù)實(shí)現(xiàn)的這些功能，如果有一個(gè)功能需要更新，那么就要改動(dòng)所有的上層模塊。所謂的DataMgr_Module只不過是把自己的所有接口都公布出來的任人欺負(fù)的家伙，公布的大部分接口都應(yīng)該是私有接口。DataMgr_Module就像是個(gè)受氣包，Manager變成了Clark。
首先要做的是恢復(fù)Manager的地位。統(tǒng)一數(shù)據(jù)結(jié)構(gòu)，統(tǒng)一傳輸協(xié)議，從上層模塊收回所有接口實(shí)現(xiàn)，規(guī)范業(yè)務(wù)流程，private所有私有接口和成員變量。Manager就該有個(gè)Manager的樣子。
模塊做到最后，我的感受是越到集成測(cè)試的時(shí)候，我就會(huì)越想念TDD。為什么呢？
DataMgr_Module一開始就采用了TDD。知道所有的PR會(huì)上確認(rèn)的接口都完成，并通過了測(cè)試用例。單元測(cè)試做的并不充分，因?yàn)楫?dāng)時(shí)沒有采用任何的測(cè)試用例方法。只是憑借自己對(duì)模塊可能存在的缺陷進(jìn)行了測(cè)試。整個(gè)單元測(cè)試的過程與其說是在測(cè)試，倒不如說是在驗(yàn)證，過程中對(duì)于錯(cuò)誤的恐懼，使測(cè)試用例漏洞百出，覆蓋效果是比較差勁的。另外一個(gè)原因是，TDD是把測(cè)試用例當(dāng)作用戶手冊(cè)的，但是，同事們根本不在意你的測(cè)試用例。別說測(cè)試用例了，有時(shí)候連注釋都懶得看，有問題直接溝通，人就是一部用戶手冊(cè)。溝通解決問題，是積極高效的，有時(shí)候是重復(fù)的。另外一個(gè)原因就是，注釋的模式不好，常常要更新同樣的3個(gè)不同位置的注釋。之前健健告訴我，應(yīng)該把這看成是必須做好的工作，就好了。但是我人比較懶，需要個(gè)好辦法，變3次為1次。（目前也沒有找到好辦法，因?yàn)槲覊焊蜎]有怎么好好找過。）
所以我常常在想，怎么樣才能讓TDD深入我的日常工作呢？
TDD的老爹Kent說如果已經(jīng)有可以運(yùn)行的代碼，這時(shí)候是不適合引入TDD的。對(duì)已經(jīng)可以運(yùn)行的261k行代碼重新寫測(cè)試用例，怕是要出人命的。我想Kent老爹說的是老代碼從新TDD，言之有理，對(duì)于一個(gè)成年人你來T他的小DD，當(dāng)然就要踢出大事情來。但是對(duì)于一些新模塊，或者說是老模塊需要徹底修改（幾乎全部拋棄）的時(shí)候，年輕人嗎，從小開始T他的小DD，慢慢培養(yǎng)，說不定能T出一個(gè)會(huì)鐵襠功的模塊來，到時(shí)候豈不是天下無敵了。
正因?yàn)镈ataMgr_Module從小開始TDD，集成測(cè)試的時(shí)候，需要增加一個(gè)接口（主要用來提高模塊的易用性）的時(shí)候，從提出需要到拆入，不過5分鐘，令用戶滿意的嘴都合不攏了。為什么啊？因?yàn)門DD了。
嘴上無毛，辦事不牢。調(diào)試除了問題，幾位用戶首先想到的是DataMgr_Module出了問題，肯定要找我。10次有8次是因?yàn)橛脩魶]有按照事先約定的協(xié)議進(jìn)行操作引起的錯(cuò)誤。為什么啊？因?yàn)門DD了。
當(dāng)然也有T的不好的時(shí)候。一個(gè)哥們把DWORD編碼的模塊，內(nèi)部全部用int代替，因?yàn)樗哉J(rèn)不會(huì)有超過0x7FFFFFFF個(gè)數(shù)據(jù)要處理。好嘛，新的規(guī)則把編碼的首位置1，0區(qū)分兩類不同數(shù)據(jù)，每次操作全是失敗。上層模塊（DataMgr_Module也是相對(duì)的上層模塊）拿著這哥們的DLL調(diào)的天昏地暗，也丈二和尚摸不著頭。沒辦法，把老兄的的代碼搞過來研究一下，原來老兄偷懶，把所有的字符串全部中轉(zhuǎn)成了int（因?yàn)闆]有現(xiàn)成的字符串到雙字的轉(zhuǎn)換函數(shù)），他T到最后也沒把這個(gè)臭蟲給T出來。Shit，害死人不抵命的啊。（于是有了上一篇瀏覽量不高的字符串轉(zhuǎn)雙字方法。）
DataMgr_Module出生，使用使得部分Module因此癱瘓，老大不得已，注釋掉了大量的代碼，最上面打上“TODO”的MsgBox，每次運(yùn)行的時(shí)候，大家都會(huì)想起我。
當(dāng)然，最后這些次生修改工作必須由我來承擔(dān)的。老大不得已，開辟了部分原來限制訪問代碼的拆出。不看則以，一看暈菜。老Clark的臭味綿延的如此之遠(yuǎn)，上至業(yè)務(wù)模塊，下至基礎(chǔ)模塊，無一不沾腥帶臭。
有一些代碼甚至到了令人發(fā)指的地步，老大Z寫的一個(gè)短短20行的函數(shù)，為了使用方便封裝成n個(gè)宏函數(shù)，并對(duì)其中的部分函數(shù)再次#define，用戶老大S為了方便，在此基礎(chǔ)上又#define了一次，不知怎么回事，老大S換了個(gè)名字又是一次#define。兩位老大在開發(fā)理念上的分歧在這短短的幾行代碼之中體現(xiàn)的淋漓盡致。Sigh，何必呢。（注：老大S是以每日Build通過為目標(biāo)，效率至上。老大Z是一完美主義者，每日Build通過是他的目標(biāo)之一，更注重Execute的代碼。兩位老大的共同點(diǎn)技術(shù)功力深厚，另外就是從未及時(shí)Meet過DeadLine。我本人更傾向于老大Z的開發(fā)理念，不過現(xiàn)在是老大S的小弟。）
看來兩位老大都有問題，到底以啥子為目標(biāo)呢？
看看微軟的一天
 每日構(gòu)造: daily build （mid-night）
 開發(fā): 解決blocking bugs, 實(shí)現(xiàn)功能, check-out, code review, check-in
 測(cè)試: BVT, 使用測(cè)試用例進(jìn)行測(cè)試
 項(xiàng)目經(jīng)理/組長: 專家會(huì)診
我們的差距在哪？
在測(cè)試上。目前團(tuán)隊(duì)大部分成員對(duì)于測(cè)試用例的理解是：由測(cè)試組在系統(tǒng)測(cè)試的時(shí)候，按照需求說明書寫出的測(cè)試用例。而單元測(cè)試的測(cè)試用例幾乎就沒有。咋整？這不就是TDD解決的問題嗎。
對(duì)于加入工程組的新模塊，開發(fā)初期需要執(zhí)行TDD，測(cè)試用例，測(cè)試用例覆蓋，到什么程度呢，如果是自己寫，就寫到自己不心虛為止吧，如果有人專門寫，那就寫到此人自己沒有困惑為止吧。
每次Debug的代價(jià)
每次Debug，需要啟動(dòng)一次HostProgram，加載所有模塊。鼠標(biāo)點(diǎn)點(diǎn)，鍵盤按按，才走到自己想要的斷點(diǎn)。每次這么搞，都感覺自己傻瓜一樣。自動(dòng)化測(cè)試測(cè)到哪，我現(xiàn)在的能力只能做沒有界面的單元測(cè)試。界面測(cè)試已經(jīng)提了需求，等著老大們開講。
對(duì)隊(duì)友離開的恐懼：
我有時(shí)候會(huì)突然冒出這樣的念頭：如果oy，或者xa離開了，我們?cè)趺崔k？項(xiàng)目會(huì)不會(huì)因此而停掉。結(jié)論是：項(xiàng)目是不會(huì)停掉的，因?yàn)槲覀冊(cè)谝粋€(gè)大艦隊(duì)中，一個(gè)小舢板部分水手的離開，老大不會(huì)坐視，新的水手稍后就到。但，進(jìn)一步的進(jìn)展是舉步維艱的。大量沒有注釋的代碼，足以讓每一個(gè)新成員崩潰。沒有注釋的代碼，是隊(duì)員變得不可或缺，人是安全的。這只是我以最壞的惡意來揣測(cè)不注釋代碼的作者。或許是趕時(shí)間吧，之前幾個(gè)版本的發(fā)布都顯得很精彩，不過軟件的內(nèi)部都是一鍋鹵煮火燒。這種看起來很美，會(huì)在用戶的手里土崩瓦解。如果是這樣的話，我們因此被團(tuán)隊(duì)拋棄，都不會(huì)再有團(tuán)隊(duì)來接納。在此之前，還是T自己狠一點(diǎn)吧。