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