??????? 這幾天一直在搞一家客戶的產(chǎn)品升級動作，數(shù)據(jù)的轉(zhuǎn)移已經(jīng)完成大部分，因?yàn)樯壷饕哪繕?biāo)是處理性能問題，所以我針對性的對將要升級的版本進(jìn)行了一些操作性能檢查，真是不做不知道，一做嚇一跳，有一個(gè)查詢選擇人員的頁面數(shù)據(jù)(60,000)的結(jié)果顯示居然花費(fèi)了50s......oh, my god

??????? 沒有辦法就仔細(xì)打開代碼開始分析，分析結(jié)果是這樣的：

??????? 1、數(shù)據(jù)綁定動作做了2次，最要命的是其中一次是直接綁定了所有60,000條數(shù)據(jù)，這直接將效率下降了40s左右(注：我們系統(tǒng)對于數(shù)據(jù)的查詢采用的是部分綁定，只綁定需要顯示的數(shù)據(jù))，修改后查詢需要時(shí)間10秒左右。
??????? 2、代碼中將數(shù)據(jù)查詢出來后又針對這些數(shù)據(jù)做了一次循環(huán)遍歷，將其中3列合并為1列，耗時(shí)3s左右......faint again...修改方式不用多說，直接將運(yùn)算動作放到了SQL中，SQL的運(yùn)行時(shí)間基本無變化。
??????? 3、SQL語句分析完后發(fā)現(xiàn)在Where子句中居然存在兩個(gè)字段直接等于的情況(WHERE PSNACCOUNT.PERSONID = PSNACCOUNT.PERSONID)，進(jìn)行了完全沒有必要的數(shù)據(jù)庫運(yùn)算，去掉后SQL語句的執(zhí)行再次提高3s，經(jīng)過代碼分析，產(chǎn)生這個(gè)條件是原因是 —— 某個(gè)公用組件的使用方法不正確......無語

??????? 經(jīng)過這次事實(shí)的經(jīng)驗(yàn)教訓(xùn)，更加讓我清楚地認(rèn)識到了Code Review的重要性，尤其是在軟件產(chǎn)品發(fā)展的過程中，一個(gè)非常簡單的道理：Code Review做的越早，產(chǎn)品就可以做得越好！

轉(zhuǎn)載于:https://www.cnblogs.com/minbear/archive/2006/07/25/459707.html

總結(jié)

以上是生活随笔為你收集整理的Code Review的重要性的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。