由于工程的文件的日益龐大和第3方庫(ACE Loki Boost等等)的使用增多
我所工作的項目系統構建時間從最初的3分鐘變為現在的8分鐘
程序員的機器配置已經很不錯了，3。0 的主頻1g的內存，但是常常由于一個小的修改導致5分鐘甚至更長的編譯時間來驗證效果。

按照《Joel on software》的說法，其直接后果是可怕的：
程序員們在這8分鐘內無所事事，只有查看網頁，或者qqmsn，打斷先前的思路從他們的上下文環境里面脫離了出來，離開了“順勢工作時間”，等到他們編譯好了驗證再修改的時候，他們又得花不少的時間來回到剛才的思路

“順勢工作時間”大致意思就是說2個不連續的半小時的效果遠不如一個連續沉浸的1小時的工作效果，如果一個人不能連續沉浸的思考，那么他就很可能陷入在不停的上下文環境切換和淺表思考當中。人的多線程處理和機器是一樣的環境的切換不能夠不考慮

所以，在當前機器配置已經沒有什么提升空間的情況下，我在項目組內部組織了一次整改活動，旨在降低編譯構建時間


1。目標：將完全重新編譯時間從8分鐘降低到4分鐘以下
2。原則：通過和主程序的溝通，并參考了《C＋＋ coding Standards》出了一下幾條整改原則:
?????首先是關于include的，因為包含頭文件相當于將代碼復制到本文件來編譯，而頭文件又經常是用來被別人包含的，所以工程文件多了，每個文件都有include鏈（包含的文件又include了其他文件），該鏈條不會止步于你工程，而會延伸到你所有使用的第3方庫里面

?????A.能夠去掉的include就去掉。

?????B.能夠在cpp里面include的頭文件不要在頭文件里面include。
?????說明：盡量去掉每個cpp會被串起來的頭文件膨脹的機會

?????C.能夠用前向聲明的就不要include，頭文件里面也是一樣
???? 說明：在頭文件里面用前向聲明然后保存指針或者引用，在具體實現的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的頭文件，而當C類需要使用Foo類時候包含Foo類的頭文件，但是操作中又需要調用A的成員函數，C不同時包含A的頭文件的花就會出現編譯失敗。

雖然表面上是讓代碼更加復雜了，但是除卻帶來降低編譯時間的好處之外，代碼也在強迫你進行解耦合，如果說你cpp里面需要包含的頭文件越多，說明你這個類需要知道的對象就越多，你可以乘機檢查一下自己的代碼又沒有不必要的耦合，為什么這個cpp需要知道那么多的本來可能屬于別的類的細節.....

??????D。把大多數模塊都要使用的庫文件或者穩定類的頭文件include放到預編譯頭文件“stdafx.h”里面
??????說明：由于預編譯頭文件里面include的內容只會compile一次而被link多次，把一些常用類放到這里會降低很多編譯時間，但也不能亂來，要點在于 “大多數”和“穩定”，如果一個頭文件經常變化，他的一次小改動都會引起整個工程rebuild，哪怕只是一個注釋，因為所有的cpp文件都包含了stdafx.h而stdafx.h又包含了這個容易變動的頭文件。
??????
??????E.使用Pimpl慣用法
??????說明：關于Pimpl大家可以查下資料，《C＋＋ coding Standards》里面也有講解，基本上就是采用一個私有的前向申明的stuct指針把所有protect成員都封裝起來起來.基本上是一個最終極的解決方案，但是對我們現有架構改造太大，不敢全面實行，我們只選擇了數個最有價值的類進行了改造，打算以后在其他項目里面再全面應用。

3。實施： 通過半個小時的溝通，讓項目組程序員了解原則，并采取結隊修改的方式來降低引入新bug的風險，在以通過原有單元測試用例的條件下，進行修改－測試－提交的迭代。???

4。結果：???編譯時間降低到了6分鐘以內。。。雖沒有達到預期，但也算有效果，沒有完全達標的主要原因還是沒有完整的測試方案包括單元測試和驗收測試，怕有些改動過大影響系統健壯性，局部放棄了一些實施的原則。


把這個整改的工作寫出來，一方面作個記錄，另外一方面希望和大家討論，相互多多交流：）


ps：
希望有過類似工作的朋友加我的
MSN：itso2_at_msn.com
大家多多溝通

公司有一個項目從vs2003移植到vs2005之后老是出現runtim erro
經過排查最終定位在fstream 打開"含中文路徑"的文件時候會出現fail的情況
本來不相信vs2003過渡到2005會有這個問題,但是經過試驗確證實了該問題
我新建立一個exe來測試該問題


vs2003不需要作任何設置就可以就可以成功
但是vs2005下每次都會失敗在斷言處,查找了一些網上資料,例如
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=371229&SiteID=1
發現但凡是uinicode的路徑都是有該問題的.
解決方法有2個
1.第一個使用vs2005默認的unicode set并在所有字符串外面面加上_T() 或者_TEXT宏,代價是原來所有不符合unicode規范的地方你都必須得改.
2.使用not set 或者"mutibyte set" 并在程序初始化的時候調用setlocale()如下

就可以解決該問題

上述引用的ms論壇連接基本講清楚了該問題,但是由于我前幾日搜索中文相關信息時候,實在未發現有用之內容,故記錄下來,希望有相同問題又不思其解的朋友可以少花點時間.

最近研究自動化構建系統(持續集成),最終發現finalbuilder十分之好用

根據網上

http://blog.dream4ever.org/dirt/archive/2005/12/20/79946.drl?

這篇文章,初步作了一個 由subversion 的post-commit 觸發的自動更新所有相關代碼編譯,并把編譯結果以及信息發送給相關人員的郵件的finalbuilder工程,目的是期望所有程序員能夠養成一種提交可編譯代碼的習慣,

其中需要用到一種叫做 subversion info 的action 類型, 其原理大概是調用 subversion/bin 里面的 svn.exe 加上參數 info 然后從標準輸出中匹配相關信息取得特定數據放到 指定的變量中,但是其action始終不能執行成功,更別提保存我需要的變量了.

經過一系列試驗,估計是由于svn在中文操作系統上返回的是類似下面的中文信息

C:\Program Files\Subversion\bin>svn info D:\LocalSvnForDailyBuild\dest
路徑：D:\LocalSvnForDailyBuild\dest
地址(URL)：http://192.168.1.100:3115/dest
Repository Root: http://192.168.1.100:3115/dest
檔案庫 UUID：47b214da-b8ec-df4b-aac3-16e2c895fbbd
修訂版：666
節點種類：目錄
調度：正常
最后修改的作者：medicer
最后修改的修訂版：666
最后修改的時間: 2006-05-18 11:58:03 +0800 (星期四, 18 五月 2006)
屬性最后更新: 2006-05-15 10:41:52 +0800 (星期一, 15 五月 2006)

而finalbuilder期望的估計是英文的輸出,所以匹配不了導致失敗

經過幾番試驗

最后把subversion 目錄 C:\Program Files\Subversion\share\locale\zh_CN\LC_MESSAGES\subversion.mo 文字信息文件刪除掉后,svn返回都使用了默認的英文,而finalbuilder也終于運行成功, 最后一次提交者提交時間都能夠正常取到!

沒有什么技術含量,只是在這里記錄下來,希望遇到相同問題的朋友可以搜索得到,不用再折騰?