淺談code review

原文連接: https://dsx2016.com/?p=710

微信公衆號: 大師兄2016

什麼是Code Review

中文爲代碼審查,是指一種有意識和系統的召集其餘程序員來檢查彼此的代碼是否有錯誤的地方.

一般進行Code Review會有如下效果:

• 更好的代碼質量,提升代碼的可維護性,統一性,可理解性等.
• 查找缺陷,發現性能問題,安全漏洞,可能的後門和惡意代碼等.
• 最佳實踐,可以更好的完成任務和需求的有效方法.
• 知識分享,review別人代碼的同時,也是學習有益技術的方式之一.

要不要Code Review

Code Review是一把雙刃劍,用的好就事半功倍,用的很差,反而對團隊和項目有不利影響.

一些道理和技術雖好,但也要看看是什麼場合和環境,因勢利導,求同存異纔是核心所在.

顯然review和其餘事物同樣,也須要花費大量的時間,對於任務本就極其緊張的團隊,在如何取捨上值得好好思考一番.

review也須要人與人之間的溝通和配合,同時也比較檢驗技術深度.

要知道,最難搞定的就是人.人都有惰性,也有本身的一套行爲準則和規範,在這個層面強加進來,很容易產生抗拒心理.

最後,怎麼說呢,試試又不吃虧,不要心存完美主義,小步快走,快速迭代,不正是軟件開發的第一要義嗎?

Code Review前置條件

Code Review自己是一件後置工做,有着查漏補缺的做用.

可是推行它也須要準備一些前置條件,可以讓團隊更快更好的去接受和實施.

• 創建團隊規範,不管是代碼層面仍是協做層面,如命名規則,語法檢查,分支規範等.
• 創建完善的文檔,方便團隊和新人查閱,在內容上你們能夠共建和建議,不能某我的一言而決.
• review流程制定,設定職責,設定週期,設定目標,從輕量級代碼審查開始,同時創建積極的審查文化.

完成上述基本骨架後,就能夠開始嘗試review了.

這一時期一般是刀耕火種的時間段,極大機率迎來各類阻力,若是推行以後的效益低於以前的,能夠在適當時間調整和放棄.

如何有效的Code Review

先不提細節,每一個團隊和技術架構都有各自的規範.

從通用的方法層面有如下幾點能夠進行有效的審查:

• 一次查看少於400行代碼
• 一次檢查不要超過30分鐘
• 使用清單(上述內容提到的團隊規範文檔,能夠更細化爲某個目標清單)

人的精力是有限的,瞭解本身的當前狀態尤其重要.

一些常見的規範和審查元素:

• 命名可讀性,能自我闡述的最好,英文用詞儘可能準確(命名是全部程序員的頭痛之一)
• 註釋,恰到好處的註釋,重要的地方及時備註,不須要的地方要刪除必定的註釋信息,代碼既是給機器運行的,也同時是交接給人看的.
• git commit提交規範,不標註信息和不及時commit都是嚴重阻擾review的因素之一,除了常規的描述信息外,還能夠按類型等備註:feat: 新特性/fix: 修改問題/refactor: 代碼重構/docs: 文檔修改/chore: 其餘修改/test: 測試用例修改/style: 代碼格式修改等等等

注意到沒,上述的都是在信息層面作文章,這也是有效溝通的方式之一.

你的代碼,你的註釋,你的提交,不只僅是業務,也同時包含了不少對外的信息,對團隊是否友好可讀,都潛移默化的表達了出來.

任何事物均可以分爲初級/中級/高級,也能夠理解爲草稿/正文/優化/美化,等層層遞進的關係和階段.

從易到難,你還能夠作如下審查(通用的居多):

• 低級的錯誤,語法錯誤,多餘變量,類型檢查,全局污染,強耦合,代碼格式化等,一般能夠先用自動化插件檢查,其次纔是人工檢查.
• 最佳實踐,避免過期的語法,避免過多的if else,避免參數過多,嘗試用新特性,語法糖,更好的設計模式,數據結構等重構代碼.
• 重複代碼,主要看有沒有把公共的組件,函數,可複用的代碼片斷抽離出來,僅此一點,可省去後期大量時間和避免錯誤發生率.
• 代碼的健壯和優雅,是否可擴展,低耦合,邏輯是否健壯,有沒有潛在的bug,保證數據和行爲的統一性,如統一錯誤提示,統一緩存等

到此涵蓋了review的一小部分,剩下的能夠自行擴展,並不是是固定的標準,每一個團隊的實現和目標都不同.

Tips

一句老生常談的話,你們都是成年人了,該作什麼,怎麼作,都要本身獨立思考,積極行動.

團隊的Code Review有沒有推行不要緊,有,當然可能更好,沒有,也並不妨礙你的自我提高.

但凡是有好的事物都應該主動去嘗試,去堅持,克服外來因素影響,一我的,也一樣能夠review本身和同事代碼.

尤爲是本身的.