1榜掌、測試數(shù)據(jù)不具有代表性优妙，導(dǎo)致功能分支測試覆蓋率不夠，真正提交測試時很容易暴露出問題憎账，對已對人都不好套硼。
2、事務(wù)使用不合理胞皱，是否在事務(wù)方法中調(diào)用外部服務(wù)邪意。有些在只讀事務(wù)操作數(shù)據(jù)，在啟用事務(wù)配置時要特別注意反砌，應(yīng)避免此類操作雾鬼。
3、對于關(guān)鍵數(shù)據(jù)未進(jìn)行為空判定宴树，一個空NullPointer異常足以打亂所有正常的業(yè)務(wù)邏輯走向策菜。
4、涉及分布式系統(tǒng)間交互數(shù)據(jù)時酒贬，無補償機(jī)制來保證數(shù)據(jù)的最終一致性又憨。也就是說非正常情況下的保障措施缺失。
5锭吨、系統(tǒng)間關(guān)鍵交易交互時蠢莺，無交易記錄留存，后期數(shù)據(jù)分析耐齐、系統(tǒng)間數(shù)據(jù)核對基本無從下手浪秘，造成一些不彌補的損失蒋情。
6、與第三方系統(tǒng)接口交互耸携，僅考慮同步數(shù)據(jù)返回棵癣，異步數(shù)據(jù)返回未編寫對應(yīng)方法，導(dǎo)致一部分業(yè)務(wù)場景下數(shù)據(jù)不一致夺衍。
7狈谊、異常信息處理欠妥當(dāng)，直接將錯誤信息返給前端用戶沟沙，體驗較差河劝。此類信息需要包裝，盡量對用戶友好矛紫。
8赎瞎、從文件布局考慮，包結(jié)構(gòu)颊咬、文件目錄結(jié)構(gòu)等安排不合理务甥，文件存放錯亂，統(tǒng)一職能文件未能統(tǒng)一規(guī)范擺放存儲喳篇，這給后續(xù)系統(tǒng)維護(hù)增加難度敞临。
9、從單個功能處理看麸澜，很正常挺尿，但推演到全局功能來講，有些功能類型或流程相同炊邦，可以采用模板模式等前人抽象出來的設(shè)計模式來重構(gòu)编矾，提升代碼的精簡性。
10铣耘、對于后期可能發(fā)生變更的功能洽沟，缺少潛在可見的擴(kuò)展性，這個可事先規(guī)劃好蜗细，完全可以兼容可以預(yù)見的變更裆操。
11、代碼兼容性比較弱的或者有些淘汰不建議的方法依舊在使用炉媒，建議換成兼容性較好的方法或替代方法踪区，一旦時間長遠(yuǎn)，這些不再兼容吊骤，極易引起bug缎岗。
12、多線程中使用了一些線程不安全的對象白粉，比如常見的日期數(shù)據(jù)格式化類SimpleDateFormate传泊，建議采用concurrent工具包里面的或Guava里面的方法或?qū)嶓w鼠渺。
13、采用數(shù)據(jù)庫進(jìn)行共享鎖操作時眷细，存在漏洞拦盹。先select再update時有時間空檔，容易被其它線程更改數(shù)據(jù)溪椎。應(yīng)直接采用update的方式直接拿數(shù)據(jù)普舆，如update table set colum=1 where colum=0
14、最后一條校读，也是比較關(guān)鍵的一條沼侣。代碼邏輯正常，但與業(yè)務(wù)邏輯不符歉秫，好比此處需要一個螺母固定蛾洛，卻放了把瑞士軍刀，雖然很強大端考，但無用雅潭。此類問題隱藏較深，所以需要Review人員經(jīng)驗豐富且對業(yè)務(wù)熟知却特，否則僅是經(jīng)驗豐富也很容易遺漏掉，造成題不對文的局面筛圆。
??????? 這兩篇內(nèi)容是筆者實際工作中總結(jié)出的幾點經(jīng)驗裂明，肯定還有其它Code Review過程產(chǎn)生的其它問題文章里沒有提及到的，有興趣的朋友可以留言在文章底部太援，把問題拋出來闽晦，群策群力不失為一個進(jìn)步的好辦法。
程序員提岔，除了編碼仙蛉，生活還應(yīng)該有沉淀！原創(chuàng)文章碱蒙，轉(zhuǎn)載請注明來源出處荠瘪。
