對於乙個做端遊的人來說，一般工程都是比較龐大的。對於編譯鏈結花的時間有時候可以去做著喝幾杯咖啡的時間浪費真是無語，還趕上有時候趕版本，真心很急…….雖然已經使用了必不可缺的incredibuild。
關於《c＋＋codingstandards》以下幾條整改原則:
關於include的原則最多，因為包含標頭檔案相當於將**複製到本檔案來編譯，而標頭檔案又經常是用來被別人包含的，所以工程檔案多了，每個檔案都有include鏈（包含的檔案又include了其他檔案），該鏈條不會止步於你工程，而會延伸到你所有使用的第3方庫裡面。
1 能夠去掉的include就去掉
（1）**編寫過程中或多或少都有一些歷史遺留的不必要的標頭檔案包含在你的檔案裡面，找到他們並去掉之。
（2）去掉include鏈裡面重複的include。當然了, 有了#ifndef …#define…#endif和#pragma once ，就算重複包含了，也只會包含編譯一次了
2 能夠在cpp裡面include的標頭檔案不要在標頭檔案裡面include。盡量去掉每個cpp會被串起來的標頭檔案膨脹的機會。如果可以使用類宣告的話，就不要用#include在標頭檔案中。
關於《effective c++》條款34中將檔案間的編譯依存關係降至最低
1 如果可以使用物件的引用和指標，就要避免使用物件本身。定義某個型別的引用和指標只會涉及到這個型別的宣告。定義此型別的物件則需要型別定義的參與。
盡可能使用類的宣告，而不使用類的定義。因為在宣告乙個函式時，如果用到某個類，是絕對不需要這個類的定義的，即使函式是通過傳值來傳遞和返回這個類，如：
classdate;
datereturnadate();
void takeadate(date d);
2 支援「編譯依存性最小化」的一般構想是：相依於宣告式，不要相依於定義式，基於此構想的兩個手段是handle class & inte***ce class;程式庫標頭檔案應該以」完全且僅有僅有宣告式」的形式存在。一般講c++設計的書中都會涉及到handle的設計理念，policy 策略，**之類，必備知識~這個如果就開始來說，你可能就得多一層處理麻煩，可是對於工程大以及以後的使用者（使用你寫的類）來說，已經與底層一些類分割開了，沒有了依存關係了。為了降低編譯依賴性，我們只要知道這麼一條就足夠了：只要有可能，盡量讓標頭檔案不要依賴於別的檔案；如果不可能，就借助於類的宣告，不要依靠類的定義。一切方法都源於這一簡單的設計思想。
關於inline的使用應該注意的
內聯函式既能夠去除函式呼叫所帶來的效率負擔又能夠保留一般函式的優點。但是它不是任何情況下都是好的。
以下情況不宜使用內聯：
1如果函式體內的**比較長，使用內聯將導致記憶體消耗代價較高。
2如果函式體內出現迴圈，那麼執行函式體內**的時間要比函式呼叫的開銷大。類的建構函式和析構函式容易讓人誤解成使用內聯更有效。要當心建構函式和析構函式可能會隱藏一些行為，如「偷偷地」執行了基類或成員物件的建構函式和析構函式。所以不要隨便地將建構函式和析構函式的定義體放在類宣告中。乙個好的編譯器將會根據函式的定義體，自動地取消不值得的內聯。
關於不debug & release 版本區別
乙個debug版可執行體要比release版大。那些額外的**都是用來支援除錯的，比如說符號的查詢，比如乙個inline函式，你會發現在debug下的反彙編還是當普通函式使用。但是，在release下，如果你的inline適合做為inline, 就可以看到它的反彙編是直接inline的。大多數實現都為debug版和release版提供了不同的operator new以及庫函式。而且，乙個release版的執行體可能已經通過多種途徑進行了優化，包括不必要的臨時物件的消除，迴圈展開，把物件移入暫存器，內聯等等。有些情況下debug版可以正常報錯，但是release不一定，如assert。所以為了都能正常執行就應該注意以下幾點,不然讓你花費額外的時間繼續來處理一些不必要的麻煩：
1. 注意變數的初始化，尤其是指標變數，陣列變數的初始化。（debug跟release在初始化變數時所做的操作是不同的）
2. 使用除錯巨集時使用後最好注釋掉。
3. 盡量使用try - catch(...)
4. 盡量使用模組，不但表達清楚而且方便除錯。
關於工作中遇到的情況
1 改變底層檔案，就算你只是改變注釋，也會導致從新編譯，真是要命！
2 編譯鏈結就算機器很新，最少也要花個幾分鐘，所以無論寫**的時候一定要做到全面檢查，邏輯理清楚，爭取一次性改好再編譯，不要改一下，編譯下，測試下，有問題，再改下，編譯下……超花時間，當然了，經驗多了，自然會好很多……
3 乙個同事說過，感覺經常做的一樣的事而抱怨，不是事情本身的問題，而是自己的問題，或許你可以嘗試不同的方式來實現，就算不是真正在工程中用到，但也是一條不同道路，或者你可以弄個更通用的，反正看你做事的態度……so so
編譯時間過長注意事項
1 修改標頭檔案後會導致較多的重編譯工作 2 能放在 cpp中的include檔案，盡量不要放在 h中 3 避免標頭檔案重複包含。下文 對於乙個中型或者以上專案，編譯時間本來就不短，如果在編碼過程中，一些問題不注意，將使編譯時間更長，下面介紹幾點需要注意的地方。關於 c coding standar...
頁面載入時間過長的解決
有時候會遇到這樣的問題 頁面載入時間很長，需要乙個友好介面來load這段空白時間，而頁面未載入的時候，頁面裡面的表單元素都是不存在的，那前台寫的初始化的js肯定是用不了了，怎麼辦？到網上搜了一下，找到了解決辦法，既然前台沒有，那我們就給它畫乙個，然後用js控制就可以了 response.write ...
訪問時間過長的排查步驟
關於 訪問時間過長的排查方式 0.先從時間上判斷,如果時間過長,則應該是故障性錯誤.時間稍長則是優化方面問題.1.首先從外層檢視,f12裡network,看看是不是有什麼檔案引用時間過長,或者載入錯誤.如果有則採用本地檔案,或者直接注釋掉.2.之後從內層原因排查,打上斷點看哪個步驟消耗的時間最長.依...