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