前沿

特別宣告：本文專為圖靈社群活動“喚醒你心中的佈道師”而寫，歡迎大家積極參與！

程式設計師雜誌第十二期中講到了企業開發的困境，其中有一點就是企業有很多的遺留程式碼，而且是C/C++的大型系統。怎麼處理一直是推動軟體開發中的頭疼問題，為什麼頭疼呢？

1. 舊程式碼，又大，怎麼下手，時間在哪裡？
2. C/C++程式碼，和java比起來沒有統一的單元測試工具，又難改造，怎麼辦？

現在我們已經基本完成了這個轉變，主要程式碼覆蓋率在60%以上，很好得支援了敏捷開發（如持續整合）。

在看了佈道之道一書後，把我們用的一些技巧和策略用實際例子和大家一起來探討一下。

背景介紹

變革開始於2007年左右，那時，這是一個有幾十萬行程式碼的C++產品，始於上個世紀末，基於Corba，XML，元件（component）的技術，由於架構的關係，沒有單元測試，只有整合測試。

功能持續增加，開發者交付壓力大。質量開始有下降、維護成本有提高的苗頭。

我們就想通過提高C++的程式碼測試覆蓋率來解決這些問題；這就需要把單元測試從無到有，再到一個高度。

基礎這麼差，不得不需要佈道！

什麼樣的懷疑者

在推動這個變革前，先看看有什麼樣的懷疑者會阻礙你。

在大公司裡最多的還是孤陋寡聞型，時間緊迫型。

孤陋寡聞型：主要是開發者，我又想叫他們埋頭苦幹型。因為他們幹活踏踏實實，只是由於專案壓力的關係，沒有額外的時間去看看外面的新技術，習慣了按步就班。

他們早已經習慣了用整合測試來替代單元測試。猛然間聽說要上單元測試，一下子就覺得不行。Java麼還可以考慮考慮，C++的產品需要搞單元測試嗎？而且這種複雜的架構，能搞成功嗎？就算能成，代價也太大了，那麼多舊的程式碼，不可能！

時間緊迫型：主要就是專案管理者，他們最大的願望是專案準時完成，質量達到要求，專案完成後，他們基本就會轉戰到另一個戰場。

所以一聽說想在專案裡面加點東西，還不知道幹嘛呢，就問多少時間？問為什麼在這個專案做（潛臺詞就是別在我這兒搗亂）。等到一聽說要做以前都不做的單元測試，頭搖得就像撥浪鼓一樣，死活都不肯。

對症下藥：採用合適的技術

對上面兩種人和我們要解決的問題，我們採用了好多種方法，下面介紹主要的兩種：展示技術和適當妥協

展示技術：你要告訴他們，你要推動的變革是可以做到的，這樣來消除他們的疑惑。

這是對付孤陋寡聞型的最好辦法，告訴他們這個能做到，也沒有想象中的難。

我記得我花了兩週的時間找了一個最典型的元件，採用了CppUnit這個單元測試框架，並應用了虛擬函式（java中的介面）的方式把對平臺架構的依賴全部隔離掉，順利地跑通了幾個測試。並且我還準備了ppt，召集大家一起來探討確認這是一個可以工作的方式。

就象書上說的，孤陋寡聞型的人看到了, 瞭解了以後，就很容易得接受你的建議了。

適當妥協：就是要找到折中方案，讓大家都能過的去。

這是對付時間緊迫型的一個好辦法，要求不能太高，把一下子想做的東西放在一個地方。

我們決定用循序漸進的方式，提出一箇中肯的方案：

1. 新程式碼必須要用單元測試，這個沒話可說，因為從專案質量上這個是可以要求的。當然怎麼做單元測試，由於是新的，會有人提供培訓和幫助。
2. 舊程式碼在改變時必須要用單元測試，因為改了程式碼，有測試保證這也是應該的。
3. 在改動的元件中，每次要對舊程式碼增加一些測試。

這樣一來，每個專案中都會對單元測試有所貢獻，長而久之，會積累到比較客觀的數量，雖然慢了點，但還是往前進步的。

時間緊迫型當然不是吃素的，老覺得虧了點，就盯著第三點說：“專案沒時間做這個額外的事情”，這個要靠策略了。

輔以策略：貫徹實施

兩個最基本的策略：竭力支持者，說服管理層。

竭力支持者 是最該採納的，他們會鼓動周邊的人和你一起服務，要善於團結他們，這要就扭成了一股繩。

對大多數有經驗的開發者，大家都明白單元測試是保證質量的最好辦法，技術上說服以後，他們很快就變成了竭力支持者，覺得不加單元測試就是一種罪過，專案中有誰忘了，竭力支持者也會及時提醒他們，不需要你們一直跟蹤，減輕了很多壓力。

說服管理層 是一個最棒的方式，當然前提是你要能說服他們。

實際上管理層也知道沒有單元測試這一弊端，只是苦於沒有行之有效的方案而已。所以當你告訴他們技術上沒有問題了，代價也不是很大，並且你又提供了切實可行的計劃。管理層立馬會通知大家把這個落實到各個專案中去（包括上面的第三條）。

拿到了這個尚方寶劍，沒有誰會阻礙了，我們就可以把主要精力花在技術支援上，當然千萬不能搞砸了。

收穫果實

果然，經過了幾年，到2010年單元測試已經達到了60%左右（對C++來說不錯了），現在開發人員也習以為常了。

結束語

佈道之道 真是一本好書（翻譯要記一功），它的好多種模式一看就明白。如果你是個有經驗的人，你會發現你的很多技巧都在書上提到了，它會幫你進一步的提煉昇華，使你下次做的更好。

佈道會使你有一種成就感，讓我們一起來把這個軟體行業變得越來越好吧。

其他

本文也是我用git記錄在github上的，你可以看到每次的變化。

如果對此文有興趣，幫忙頂一下，別忘了 @larrycaiyu ，希望有機會有人能幫我推薦到QConf 2012中去分享，到時我們可以探討得更多。

這兒再留一個關子，如何建立一個好的C++程式碼質量檢測框架，並且最終和其他java程式碼質量清晰得顯示在一起又是另外一個佈道故事了，而且有一些就是因為沒有看這本書而得到的一個反面教材。