程式碼評審的三怕
評審程式碼的流程
我自己總結的評審程式碼的流程，僅供參考：
1>確認程式碼的修改範圍
2>梳理修改的部分的處理流程，之前沒有流程圖，需要先畫流程圖
3>進行邏輯正確性評審
4>對照程式碼規範和評審checklist進行規範性評審
三怕
一怕依賴版本更新
二怕檢查出來的問題太多
三怕隨手優化
依賴版本更新
依賴版本更新又分為兩種，一種是二方庫更新，另外一種是三方庫更新。名詞解釋下：
一方庫：本工程內部子項目模組依賴的庫(jar包)；
二方庫：公司內部發布到中央倉庫，可供公司內部其他應用依賴的庫(jar包)；
三方庫：公司之外的開源庫(jar包)。
二方庫更新，一般來說，由於是公司內部的，有任何變更需要涉及方更新時都會通知，實際的改動量不會特別多。這時候升級前需要做版本比對，確認所有的修改處，尤其要注意：枚舉值的順序、方法的順序是否有變換；方法是否有重載。
之前發生過由於在枚舉值中間添加了新的枚舉造成的故障。這和序列化和反序列化的實現有關。我之前的文章《JAVA數據處理的常用技術》里有提到protostuff這樣的序列化方式之所以更省空間，是因為把原本的方法名比如thisIsMethod1做了編號，比如標記為1，程式碼這是第一個方法。而不是原本的名字。如果升級版本，比如thisIsMethod1和thisIsMethod2之間加了一個thisIsNewMethod。原本編號為:1,:2的實際上變成了:1,:3,:2。而序列化版本號沒有同步更新，解析時會認為是:1,:2,:3，這時候會造成解析錯誤。如果覺得上面我說的不夠清楚，可以這麼來理解：有壓縮功能的二進位演算法都是有代價的，代價就是需要遵循一定規則，升級很可能會打破這個規則，造成錯誤。
三方庫更新，通常由於漏洞會被要求升級，比如fastjson。對這類問題，首先明確這個jar引入解決的問題，針對這些功能做回歸；第二，一個團隊有多個應用的話，非核心應用先升級；第三，跟隨策略，對於重要的服務，先等其他團隊升級線上運行一段時間沒有發現問題再升級；第四，盡量拉長灰度周期，避免小概率邏輯暫時沒有驗證到。
從上面二方庫和三方庫的升級方法來看，二者的升級都需要不小的工作量，作為程式碼評審的人要對結果負責。所以工作不僅是評審程式碼，還要確保上面需要的工作都做到位了。
檢查出來的問題太多
很多編程人員可能都有這樣的感受：在第一遍進行編碼的時候，每一步會考慮的很周全細緻。但是編寫完成後一旦涉及到修改，可能就會改不全。最冤枉的是原來的程式碼本來問題也不大，只是風格不符合程式碼評審人員的習慣。結果評審人員非要編碼人員改了，結果沒改全出現了問題。雖然有一些手段進行規避，比如單元測試。但是修改的代價還是很高。我在進行程式碼評審的時候，第一件事是確認程式碼編寫人員的修改範圍，看看這個修改範圍我之前有沒有對邏輯做細緻的梳理。如果沒有梳理過，那我先梳理一遍，照著梳理的內容進行評審。程式碼風格的問題我會給出建議，但不會為此卡著不允許合入。畢竟為了避免程式出現邏輯問題，我每次把別人的程式碼打回去，下次提交我要照著梳理的邏輯整體全部重新評審一遍，避免疏漏。實際工作中概率統計：一個流程任務的執行。如果被檢查出來的錯誤太多，說明有兩點都做的不好：1>流程本身就有漏洞，沒有標準化；2>執行者無腦或者缺腦的在執行。這樣，檢查人員要無限制的去做兜底。
對於寫程式碼來說，如果程式碼寫的漏洞百出，那說明方案評審階段很多事情就沒有理順；寫程式碼的人考慮問題也不夠全面甚至沒有仔細思考就動手寫了。最可怕的是評審出來問題後，評審人讓寫程式碼者改什麼，寫程式碼者就是無腦照辦。評審人很可能由於使用腦補細節有疏漏，造成問題。
隨手優化
在《避免線上故障的10條建議》和《設計開發中要避免的兩個坑和一種可借鑒的設計思想》里我都有詳細說明過，隨手優化可能會帶來的災難。但是最近寫程式碼才發現這件事情我自己也沒做好。
最近我提交了一次程式碼，被認真負責的同事加了評論打回了。第一條在一個地方給我打了個問號。這個地方我的修改是：在一個方法里，一個程式碼片段和下面的程式碼片段中間有2個空行。」因為我看著極為不爽就隨手去掉了一個多餘的空行。我看著打回的程式碼，本來是想解釋一下，後來我仔細想了一下：
1>多一個空行完全不影響運行，也不會增加很多理解成本，本身必要性不大
2>我改了一個空行測試驗證過嗎？就算是理論上完全不影響生產，不經過測試的修改是不對的。
所以我默默的放下驕傲，還原了隨手優化的程式碼。
後記
細節決定成敗。剛畢業的時候，我們幾個應屆生一起做項目，做的都不是什麼核心功能。就是C/S模式的客戶端交互介面。我和旁邊一個女孩相比。我做了7個介面，她做了1個。並且我的介面都比她的複雜。最後我做完了，她還沒有做完，她延期了好久。最終領導說她做的好，我當時是非常不服氣的。後來我想明白了：就像99%的時間會花在線上只有1%幾率出現的問題一樣。多囫圇吞棗的做事情並不多花多少時間，而想把品質提高一些，做的更好一些，卻是更難的事。平時買東西也一樣，品質高出一些，做工精巧一些，價錢多出好幾個數量級；小時候考試也一樣，從班裡倒數第一進步到中等水平並不難，但是從第二名進步到第一名要的功夫就大多了；普通飯館裡冷盤十幾元到幾十元一盤，用了刀工的大廚做的那價錢會翻10倍甚至更高，一個道理。
推薦閱讀
