大專案中稍不注意，編譯連結速度就逐漸變慢。如果沒人關心這個問題（就像我現在這個公司），專案開發效率就會降低，軟體質量下降。程式設計師有充足的理由怠工和玩手機（因為正在編譯），這些精力本應該投入到對軟體的思考上去的。如果專案經理繼續忽略這個問題，這個問題早晚會爆發出來，可能是在客戶交流會議上或產品交付時。

我們有下面這些問題:

1) 不知道pimpl手法

專案組進進出出幾十號人了，幾乎沒用過pimpl手法。寧願在class定義中宣告一堆私有成員，也不願意把它們真正隱藏在實現檔案內。

2) 為了省事，建立一個超級include檔案。

用這個超級include檔案，先預先include入可能需要的大多數檔案。就是為了能少敲入很多include語句行呢！真實懶到家了，多敲入幾行include能累死人？

這個嫌累了，專案延期加班就不嫌累了？

3）不用前向宣告

前向宣告都很少用，無語了。給主管說這個事（博士出身），不以為然。怪不得你領導的產品，客戶嚷嚷著要退貨呢，你自己也會大學回回爐吧！

4）設計時不知道強內聚，弱耦合

不管是面向過程，面向物件，還是面向宇宙程式設計，這個規律一直是主導的啊！設計時，不管不顧，編譯時肯定互相牽連，拖慢速度呀！

給人家說這個詞，就好像對牛彈琴一樣。這種公司留住人才才怪。

5）不用預編譯頭

pch不用，解釋說是個別工程編譯不出來了。無語了，那應該是設定問題，或者stdadx.h中的東西需要精簡一下了。

6）boost竟然用靜態庫版本

一大堆dll需要編譯，每個dll竟然都靜態連結boost庫。既然知道dll能加快編譯和連結速度，卻不懂boost庫居然有動態庫版本

7）幸好知道用分散式編譯

但是連結時間超長，也沒人發現（發現了也沒人管）。公司用incredibuild。通過設定某些選項可以加快連結速度

最簡單的解決方法是：關閉incredibuild的連結階段，讓vs工具自己連結程式。

8）/MP選項未開啟

此為多CPU並行編譯，可提高編譯速度

9）破機器，不捨得升級

給上級提硬體升級的事，不捨得。這個世界人力成本太高了。寧願招聘一大堆不合格的程式設計師，也不願意升級硬體配置。

我做領導，高薪招幾個高手，配高檔機器，做出的東西肯定比一堆菜鳥配低端機器的產品強！