項(xiàng)目極其需要一次深入的代碼重構(gòu)與性能提升，而這都至少需要一個(gè)release的時(shí)間來做，對(duì)于代碼重構(gòu)， 從商業(yè)的角度來講，是十分不可取的，一是其風(fēng)險(xiǎn)比較大，大刀闊斧的重構(gòu)，如何保證軟件的原有功能是個(gè)大問題； 而整整一個(gè)release的時(shí)間做重構(gòu)，對(duì)于用戶來講，他拿到新的版本時(shí)，看不到任何新功能與提高，難道你告訴他，我們的代碼結(jié)構(gòu)現(xiàn)在很elegent。。。；但對(duì)于性能提升，現(xiàn)在是到了不得不做的地步，因?yàn)槟軌虼蠓鹊奶嵘阅?，想必用戶也能接受一個(gè)沒有新功能的新版本。

    于是， 我們決定用一個(gè)release的時(shí)間來做性能優(yōu)化。

    當(dāng)然，我們不打算從學(xué)術(shù)的角度來考慮， 這個(gè)是O(n) 的算法，那個(gè)是O(nlgn) 的。。。； 也不打算從語言的角度來看待， 傳引用要比傳值快，類成員在初始化列表初始化。。。；當(dāng)然， 并不是說這些不重要， 只是這些都應(yīng)該是比較常見的，大家都應(yīng)該清楚的事情， 也就是說我們假設(shè)我們的項(xiàng)目中不存在這種問題； 另外就是從語言角度來做的優(yōu)化， 對(duì)我們的性能提升幫助不會(huì)太大。 我們會(huì)從一個(gè)宏觀的，特定于我們項(xiàng)目workflow方面的角度來做優(yōu)化。 主要包括以下幾個(gè)方面：

     一、集中處理 (batch processing)

     把相關(guān)的操作集中起來處理， 從程序原理上來講， 集中做相同的操作， 由于數(shù)據(jù)局部性的原理， 很多數(shù)據(jù)可以直接從cache中取得， 速度會(huì)比較快。 但我們主要考慮的還是另外一個(gè)因素，減少不必要的重復(fù)的初始化，假設(shè)將我有十個(gè)對(duì)象要update， 一般情況下， 為了做update， 我們必然要準(zhǔn)備某些前提數(shù)據(jù)， 如果十個(gè)對(duì)象分別處理， 我就要初始化十次， 但如果我先把這十個(gè)對(duì)象收集起來，到最后一起處理， 最后只會(huì)初始化一次前提數(shù)據(jù)。 這對(duì)于update對(duì)象密集的情況十分有用。 當(dāng)然， 這樣我們也能有效的減少函數(shù)調(diào)用次數(shù)， 對(duì)性能提高也有不少的幫助。

     二、減少重復(fù)操作（初始化） (reduce repeated operations)

      重復(fù)操作， 一個(gè)是在有循環(huán)的時(shí)候， 我應(yīng)該盡量把一些common的操作， 如一些輸入數(shù)據(jù)的初始化提到循環(huán)外面來做，這在上面一點(diǎn)中也提到過。 二是對(duì)于一些全局的屬性，操作等， 我們應(yīng)該放在內(nèi)存里，并提供一個(gè)全局訪問點(diǎn)來直接得到， 而不是每次在需要的時(shí)候都去重新初始化一遍。 舉個(gè)例子來講， 每個(gè)application應(yīng)該都有他自己的一些configuration, setting, 如果每次我需要這些信息的時(shí)候， 都從文件，或者注冊(cè)表去讀一次， 那就非常的浪費(fèi)時(shí)間了， 尤其是涉及到I/O操作的時(shí)候。 當(dāng)然， 這個(gè)有點(diǎn)像 cache的概念， 但是還遠(yuǎn)遠(yuǎn)不及。

     三、消除冗余操作 (avoid redundant operations)

    也許你不相信， 一個(gè)項(xiàng)目經(jīng)過很多不同的人的開發(fā)， 由于理解上的誤差，以及時(shí)間緊迫倉促完工，很多workflow上可能會(huì)都重復(fù)的操作， 仔細(xì)檢察， 從全局上來考慮整個(gè)流程，你會(huì)發(fā)現(xiàn)， 其實(shí)我們做了很多不該做的事。

     四、cache機(jī)制 (cache mechanism)

     Cache的原理是用空間換時(shí)間， 當(dāng)然，這個(gè)空間是指內(nèi)存。我們把一些重要的中間信息放在內(nèi)存中，以極大的提高查找，更新的速度。一般常用的數(shù)據(jù)結(jié)構(gòu)就是map, 比如一個(gè)對(duì)象有長(zhǎng)度這么一個(gè)屬性， 但每次去得這個(gè)長(zhǎng)度的時(shí)候都需要經(jīng)過復(fù)雜的耗時(shí)的計(jì)算， 如果我們有些操作需要大量的使用到這個(gè)對(duì)象及其屬性， 我們就可以建這樣一個(gè)map: map<對(duì)象指針，長(zhǎng)度>， 這樣每次用到時(shí)， 我只要到這個(gè)map中去查就可以了， 如果某個(gè)對(duì)象被更新了，我們需要更新這個(gè)map, 也就是說維護(hù)cache.

     五、延遲更新 (defer update)

      這是一個(gè)講究策略的做法， 比如說我們的項(xiàng)目要在9.1號(hào)前demo給客戶， 我們要寫好代碼，并維護(hù)好文檔， 但是時(shí)間很急， 如果我們?cè)?/span>9.1號(hào)前把這兩件時(shí)都要做好，恐怕要瘋狂加班了， 但是我們知道，客戶只需要看到我們軟件運(yùn)行的效果， 文檔他暫時(shí)并不關(guān)心， 那好吧， 我們9.1前就寫代碼， 文檔就在demo后寫好了。當(dāng)然舉這個(gè)例子的并不是鼓勵(lì)大家先寫代碼，后補(bǔ)文檔， 而是為了說明有些事情， 如果資源緊張， 我們可以把他分開看待，對(duì)于要的不急的那部分， 我們可以先不做， 等到時(shí)不忙了， 需要了的時(shí)候再做， 以緩解當(dāng)前的緊張。 從代碼角度舉個(gè)例子， 假設(shè)我們有十條樣條曲線需要更新， 更新可能包括樣條線的方程，圖形顯示， 以及其長(zhǎng)度等等， 如果我這些事情我一下子全做了， 用戶可能要等很久， 但是我們知道， 用戶做了這個(gè)操作， 他只需要看到圖形上更新就可以了， 至于長(zhǎng)度等什么的， 等他需要了， 或者空閑的時(shí)候，我們?cè)俳o他更新， 這就讓整個(gè)操作比較流暢了。

     這是我通過這個(gè)release對(duì)軟件優(yōu)化的一些想法，我相信現(xiàn)實(shí)中優(yōu)化的方法是多種多樣的，我希望這篇文章能夠起到拋磚引玉的作用，希望大家能夠提出自己的一些經(jīng)驗(yàn)來共同分享。