由于工程的文件的日益龐大和第3方庫(ACE Loki Boost等等)的使用增多
我所工作的項目系統(tǒng)構(gòu)建時間從最初的3分鐘變?yōu)楝F(xiàn)在的8分鐘
程序員的機器配置已經(jīng)很不錯了，3。0 的主頻1g的內(nèi)存，但是常常由于一個小的修改導(dǎo)致5分鐘甚至更長的編譯時間來驗證效果。
按照《Joel on software》的說法，其直接后果是可怕的：
程序員們在這8分鐘內(nèi)無所事事，只有查看網(wǎng)頁，或者qqmsn，打斷先前的思路從他們的上下文環(huán)境里面脫離了出來，離開了“順勢工作時間”，等到他們編譯好了驗證再修改的時候，他們又得花不少的時間來回到剛才的思路
“順勢工作時間”大致意思就是說2個不連續(xù)的半小時的效果遠(yuǎn)不如一個連續(xù)沉浸的1小時的工作效果，如果一個人不能連續(xù)沉浸的思考，那么他就很可能陷入在不停的上下文環(huán)境切換和淺表思考當(dāng)中。人的多線程處理和機器是一樣的環(huán)境的切換不能夠不考慮
所以，在當(dāng)前機器配置已經(jīng)沒有什么提升空間的情況下，我在項目組內(nèi)部組織了一次整改活動，旨在降低編譯構(gòu)建時間
1。
目標(biāo)：將完全重新編譯時間從8分鐘降低到4分鐘以下
2。
原則：通過和主程序的溝通，并參考了《C＋＋ coding Standards》出了一下幾條整改原則:
?????首先是關(guān)于include的，因為包含頭文件相當(dāng)于將代碼復(fù)制到本文件來編譯，而頭文件又經(jīng)常是用來被別人包含的，所以工程文件多了，每個文件都有include鏈（包含的文件又include了其他文件），該鏈條不會止步于你工程，而會延伸到你所有使用的第3方庫里面
?????A.
能夠去掉的include就去掉。
?????B.
能夠在cpp
里面include的頭文件不要在頭文件里面include。
?????說明：盡量去掉每個cpp會被串起來的頭文件膨脹的機會
?????
C.能夠用前向聲明的就不要include，頭文件里面也是一樣
???? 說明：在頭文件里面用前向聲明然后保存指針或者引用，在具體實現(xiàn)的cpp里面再包含頭文件，雖然看起來和《C＋＋ coding Standards》“
Make header files self-sufficient”有些沖突（前兩天另外cppblog一位朋友講過
http://www.shnenglu.com/flyingxu/archive/2006/06/23/8908.html）但是在一些核心的.h(被很多類include的)里面作改造工作，還是能夠收到很大的降低編譯時間效果，而付出的代價就是原來只需要包含該頭文件就可以編譯成功的cpp需要額外包含一些頭文件。
舉個例子： Foo類頭文件使用了前向申明保存了A類和B類的指針或者引用為成員變量，在Foo類的cpp里面才包含A和B的頭文件，而當(dāng)C類需要使用Foo類時候包含F(xiàn)oo類的頭文件，但是操作中又需要調(diào)用A的成員函數(shù)，C不同時包含A的頭文件的花就會出現(xiàn)編譯失敗。
雖然表面上是讓代碼更加復(fù)雜了，但是除卻帶來降低編譯時間的好處之外，代碼也在強迫你進(jìn)行解耦合，如果說你cpp里面需要包含的頭文件越多，說明你這個類需要知道的對象就越多，你可以乘機檢查一下自己的代碼又沒有不必要的耦合，為什么這個cpp需要知道那么多的本來可能屬于別的類的細(xì)節(jié).....
??????D。
把大多數(shù)模塊都要使用的庫文件或者穩(wěn)定類的頭文件include放到預(yù)編譯頭文件“stdafx.h”里面
??????說明：由于預(yù)編譯頭文件里面include的內(nèi)容只會compile一次而被link多次，把一些常用類放到這里會降低很多編譯時間，但也不能亂來，要點在于 “大多數(shù)”和“穩(wěn)定”，如果一個頭文件經(jīng)常變化，他的一次小改動都會引起整個工程rebuild，哪怕只是一個注釋，因為所有的cpp文件都包含了stdafx.h而stdafx.h又包含了這個容易變動的頭文件。
??????
??????
E.使用Pimpl慣用法
??????說明：關(guān)于Pimpl大家可以查下資料，《C＋＋ coding Standards》里面也有講解，基本上就是采用一個私有的前向申明的stuct指針把所有protect成員都封裝起來起來.基本上是一個最終極的解決方案，但是對我們現(xiàn)有架構(gòu)改造太大，不敢全面實行，我們只選擇了數(shù)個最有價值的類進(jìn)行了改造，打算以后在其他項目里面再全面應(yīng)用。
3。實施： 通過半個小時的溝通，讓項目組程序員了解原則，并采取結(jié)隊修改的方式來降低引入新bug的風(fēng)險，在以通過原有單元測試用例的條件下，進(jìn)行修改－測試－提交的迭代。
???
4。結(jié)果：???編譯時間降低到了6分鐘以內(nèi)。。。雖沒有達(dá)到預(yù)期，但也算有效果，沒有完全達(dá)標(biāo)的主要原因還是沒有完整的測試方案包括單元測試和驗收測試，怕有些改動過大影響系統(tǒng)健壯性，局部放棄了一些實施的原則。
把這個整改的工作寫出來，一方面作個記錄，另外一方面希望和大家討論，相互多多交流：）
ps：
希望有過類似工作的朋友加我的
MSN：itso2_at_msn.com
大家多多溝通