關(guān)于Code Review的重要性，我相信好的工程師都能認(rèn)識到。 參考 "讓Code Review稱為一種習(xí)慣" 和 "從Code Review談如何做技術(shù)"。

創(chuàng)新互聯(lián)建站是專業(yè)的尋烏網(wǎng)站建設(shè)公司，尋烏接單;提供成都網(wǎng)站制作、網(wǎng)站建設(shè),網(wǎng)頁設(shè)計,網(wǎng)站設(shè)計,建網(wǎng)站,PHP網(wǎng)站建設(shè)等專業(yè)做網(wǎng)站服務(wù);采用PHP框架,可快速的進(jìn)行尋烏網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴(kuò)展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團(tuán)隊,希望更多企業(yè)前來合作!

同時引用一下有人對Google Code Review的描述：

The biggest thing that makes Google’s code so good is simple: code review. At Google, no code, for any product, for any project, gets checked in until it gets a positive review.

Code Review 主要Revivew什么

Architecture/Design

單一職責(zé)原則.

這是經(jīng)常被違背的原則。一個類只能干一個事情, 一個方法最好也只干一件事情。 比較常見的違背是處理促銷的時候，同時處理驗券邏輯。

行為是否統(tǒng)一

比如緩存是否統(tǒng)一，錯誤處理是否統(tǒng)一， 日志打印是否統(tǒng)一， 方法實現(xiàn)是否統(tǒng)一等等。

同一邏輯/同一行為 有沒有走同一Code Path？低質(zhì)量程序的另一個特征是，同一行為/同一邏輯，因為出現(xiàn)在不同的地方或者被不同的方式觸發(fā)，沒有走同一Code Path 或者各處有一份copy的實現(xiàn)， 導(dǎo)致非常難以維護(hù)。

代碼污染

使用魔數(shù)，例如直接比對數(shù)字。編寫不容易閱讀的代碼，應(yīng)用了很多復(fù)雜的設(shè)計。

重復(fù)代碼

主要看有沒有把公用組件，可復(fù)用的代碼，函數(shù)抽取出來。

Open/Closed 原則

就是好不好擴(kuò)展。 Open for extension, closed for modification.（做好接口設(shè)計會很好解決這些問題）。

面向接口編程 和 不是 面向?qū)崿F(xiàn)編程

主要就是看有沒有進(jìn)行合適的抽象， 把一些行為抽象為接口。

健壯性

對Corner case有沒有考慮完整，邏輯是否健壯？有沒有潛在的bug？

有沒有內(nèi)存泄漏？有沒有循環(huán)依賴?（針對特定語言，比如Objective-C) ？有沒有野指針？

有沒有考慮線程安全性， 數(shù)據(jù)訪問的一致性

錯誤處理

有沒有很好的Error Handling？比如Price接口出錯。

有沒有增加必要的監(jiān)控，及時報警。

改動是不是對代碼的提升

新的改動是打補丁，讓代碼質(zhì)量繼續(xù)惡化，還是對代碼質(zhì)量做了修復(fù)？

效率/性能

兩層循環(huán)，數(shù)據(jù)請求量的限制，較大數(shù)據(jù)等耗時操作是否處理得當(dāng)。

關(guān)鍵算法的時間復(fù)雜度多少？有沒有可能有潛在的性能瓶頸。

復(fù)雜需求，是否有必要的設(shè)計， 可預(yù)見的效率問題， 開發(fā)模式一致性的問題 應(yīng)該盡早在Design Review階段解決。如果Design階段沒有解決，那至少在Code Review階段也要把它找出來。

Style

可讀性

衡量可讀性的可以有很好實踐的標(biāo)準(zhǔn)，就是Reviewer能否非常容易的理解這個代碼。 如果不是，那意味著代碼的可讀性要進(jìn)行改進(jìn)。

命名對可讀性非常重要，我傾向于函數(shù)名/方法名長一點都沒關(guān)系，必須是能自我闡述的。

英語用詞盡量準(zhǔn)確一點（哪怕有時候需要借助Google Translate，是值得的）

函數(shù)長度/類長度

函數(shù)太長的不好閱讀。 類太長了，比如超過了1000行，那你要看一下是否違反的“單一職責(zé)” 原則。

恰到好處的注釋。 但更多我看到比較差質(zhì)量的工程的一個特點是缺少注釋。

參數(shù)個數(shù)（不要超過5個參數(shù)）

Review Your Own Code First

跟著名的橡皮鴨調(diào)試法（Rubber Duck Debugging）一樣，每次提交前整體把自己的代碼過一遍非常有幫助，尤其是看看有沒有犯低級錯誤。

如何進(jìn)行Code Review

多問問題。多問 “這塊兒是怎么工作的？” “如果有XXX case，你這個怎么處理？”

每次提交的代碼不要太多，最好不要超過1000行，否則review起來效率會非常低。

當(dāng)面討論代替Comments。 大部分情況下小組內(nèi)的同事是坐在一起的，face to face的 code review是非常有效的。

區(qū)分重點，不要舍本逐末。 優(yōu)先抓住 設(shè)計，可讀性，健壯性等重點問題。

Code Review的意識

作為一個Developer , 不僅要Deliver working code, 還要Deliver maintainable code.

必要時進(jìn)行重構(gòu)，隨著項目的迭代，在計劃新增功能的同時，開發(fā)要主動計劃重構(gòu)的工作項。

開放的心態(tài)，虛心接受大家的Review Comments。

審核人及職責(zé)分配
所謂職責(zé)歸屬：即指誰對這個Code負(fù)責(zé)

提交人

審核人

職責(zé)歸屬

P2.1及以下

P2.3

審核人

P2.2及以上

P2.3

提交人&審核人

p2.3及以上

p3.1/p3.2

提交人&審核人

對于comments的檢查。周會上抽查。

審核流程
開始
RD完成開發(fā)自測
自查不過
自查通過
Review your
own code
RD按照comment意見修改
重新自測并重新提交代碼
是
否
是否可以Merge
Merge至主分支
1.只有主分支權(quán)限的人才能Merge

結(jié)束
是
否
是否需要
代碼走讀
RD發(fā)起Code Review
跟著名的橡皮鴨調(diào)試法（Rubber Duck Debugging）一樣，每次提交前整體把自己的代碼過一遍非常有幫助，尤其是看看有沒有犯低級錯誤。
是否走讀標(biāo)準(zhǔn)
1.修改了核心鏈路代碼；
2.修改代碼行數(shù)> 600 行；
3.修改公用業(yè)務(wù)組件或邏輯；
4.審核人提出走讀意見；
1.按照要求選擇審核人；
2.設(shè)置PR完成時間；
3.補充code主要變動范圍
4.跟進(jìn)PR完成狀態(tài)
發(fā)起人組織
Code Review會
stash上同步記錄 commits
否
Review
是否通過
merge條件：
1.approve >= 2人；
2.comment 都完成修改；

備注標(biāo)簽
流程節(jié)點
分支判斷
圖示例

常見代碼開發(fā)規(guī)范

thrift服務(wù)提供一般情況都需要在finally里輸出info級的入?yún)⒑头祷貐?shù)的日志

實現(xiàn)Object的toString方法而不是使用json序列化工具輸出日志

Integer的等值使用equals而不是==

使用apache commons 包而不是自己造輪子

組織參數(shù)抽取方法來完成而不要在service里面寫，方法命名規(guī)范成buildXXXXX

線程池的使用需要統(tǒng)一到一個Utils類中，避免線程池定義泛濫。

所有遠(yuǎn)程服務(wù)調(diào)用都需要封裝delegate類，禁止直接使用octo客戶端進(jìn)行調(diào)用。在真正調(diào)用一般都要finally里輸出info日志 入?yún)⒑头祷刂怠?/p>

靜態(tài)變量需要統(tǒng)一在一個類中定義。

OCTO生成的類不要傳遞到service層，構(gòu)造一個本地類進(jìn)行使用。

不要把配置寫在代碼里，充分利用MCC和*.properties

MCC里配置開關(guān)和頻繁修改的屬性，長期不修改的放到*.properties

給方法起名字是為了自己和其他人能看懂

變量命名以及方法名不要使用拼音縮寫

Json序列化統(tǒng)一使用travel-insurance-common表里的JsonUtils

不要在ThriftService里寫業(yè)務(wù)邏輯。下沉service

不要拷貝代碼

執(zhí)行update語句一定要注意 where 條件里 一定要走索引，這句話的意思是，把where 條件單獨放一個select里 然后explain一下，如果是全表掃描 那這個SQL會鎖全表。

不要在返回boolean的方法里面寫if (xxxxx&xxxx){return true}else{ return false}

永遠(yuǎn)不要在事務(wù)里rpc

拋出異常最好子類化，這樣從cat看到異常就知道是啥原因。

邏輯嵌套不要超過3層

@Transactional(rollbackFor =Exception.class) 使用事務(wù)的時候 一般情況這么用。

查詢不要使用mybatis生成的condition來拼，mybatis生成工具只負(fù)責(zé)生成表的po和最基本的insert 和update ，如果有分表，請所有sql全部手寫，必須帶分表鍵。

不要在static{}代碼塊里做初始化動作，禁止在static{}代碼塊里rpc

網(wǎng)站欄目：如何進(jìn)行CodeView
轉(zhuǎn)載注明：http://www.chinadenli.net/article48/jdjpep.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供小程序開發(fā)、網(wǎng)站導(dǎo)航、網(wǎng)站設(shè)計、企業(yè)建站、品牌網(wǎng)站設(shè)計、靜態(tài)網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)