作者:京東物流 馮志文
前言
本文參考《京東JAVA代碼規范-V1.1》&Google代碼評審工程實踐方法論,結合團隊代碼評審的實踐經驗整理成文檔,這份文檔是我們團隊集體經驗的結晶。我相信公司其他部門也有類似的經驗和最佳實踐。希望通過互相交流和學習,共同提高代碼質量,進而提高系統的穩定性。
名詞解釋:
CL: “changelist”修改列表,它是提交到coding版本控制工具中的一次代碼修改(即將審核的代碼)
CR:CodeReview代碼評審
一、為什么需要CR
代碼質量是軟件質量的基石
1.我們進行代碼評審的目的是為了提升代碼質量,盡早發現潛在缺陷與BUG,降低修復成本。同時,這也有助于促進團隊內部的知識共享,幫助更多人更好地理解我們的系統。
2.從系統的角度來看,代碼審查可以幫助我們提前發現問題,減少bug,提高穩定性,避免到處救火的情況發生。
3.從開發人員來看,代碼評審是一個逐步改正不良習慣的過程,可以提高編碼、設計、架構能力。讓他們從自身犯過的錯誤中學習,并從他人的思路中成長。
4.從評審者來看,這也是一個學習他人編碼能力的機會。我們可以從他們的經驗和技巧中汲取養分,不斷提高自己的專業素養。
5.從團隊管理來看,代碼評審提高團隊凝聚力,熟悉彼此的模塊業務。這將使我們更加團結協作,降低因人員流失帶來的成本和風險。
......
請記住,代碼評審不是批斗會。我們的目標是針對代碼本身,而不是針對人。我們應該以建設性的方式提出問題和改進意見,以幫助開發人員提高編程技能和整體水平。
最后,請確保團隊所有開發者都理解并接受這個流程。如果團隊有人對此產生抵觸或反感,那么這個目的就無法實現。小組剛開始代碼評審也是這樣,大家總覺得不好意思指出別人的不合理之處。因此,請大家共同努力,讓代碼評審成為我們團隊文化的一部分。
二、CR流程規范
CR前提條件:
1.本地通過IDEA各種插件檢查一般性的錯誤。比如使用JoyCoder、京東編碼規約、Sonar等
2.自測通過,確?;竟δ芰鞒虥]問題
將CR前置,避免到最后上線的時候合并到Master做CR。履約需求上線CR至少經過2輪,第一次是提測前,最后一輪是上線前。每一輪的側重點不一樣。流程如下:
備注:Dev分支主要作用local代碼庫的遠程備份,這個備份動作是通過不斷commit&push完成,所以不用擔心代碼丟失。Feature分支承擔功能測試和CR的作用,因為有Dev一層屏蔽了中途反復地修改,使得提交地PR更為清晰。Master是上線使用的分支。
第一次CR:
項目提測前(合并到feature分支)
1.為什么是測試前?
2.如果都測試完成了要上線了,CR的意義在哪里?CR發現的很多問題還改不改?
3.提測前CR反饋的問題細致全面,研發可以及時修復。
中間CR:
(合并到feature分支)
1.主要是修復測試提的BUG之類,或者這個需求很久了,需要重新拉取最新的線上代碼master
最后一次CR:
上線前(合并master主干)
1.這時候核心是CR代碼沖突,代碼是否有遺漏,配置是否準確?上線是否有其他風險點?
切記代碼上線前的最后一次CR后,務必需要經過測試回歸驗證,引流驗證等,以防合并代碼遺漏等情況。對上線前代碼再次回歸驗證沒問題后才可以上線
代碼評審 整個過程 分為 評審者和開發中。接下來分別解釋下評審者指南和開發者指南。
三、代碼評審者指南
在進行代碼評審時,我們可以從不同的角度出發,包括評審者和開發者的角度來進行。
首先,從評審者的角度來看,我們需要了解一些評審的指南。這些指南包括:
1.哪些人可以參與代碼審核?
2.評審方式有哪些?標準是什么?
3.評審者應該關注哪些?
1、哪些人可以參與代碼審核呢?
1.小組長TL:從團隊角度出發,需要有全局觀,重點關注【穩定性】【代碼可讀性】等
2.架構師:從系統架構出發,核心關注【代碼思路是否和架構設計一致】
3.核心骨干:為了確保代碼質量和項目穩定性,我們通常會選擇團隊中最優秀的代碼審核者來進行審核。這個人應該具備足夠的經驗和技能,能夠在你期望的時間內對審核工作負責。
4.團隊成員:如果長期是核心骨干CR,這樣會導致團隊其他人員參與度不高,需鼓勵團隊其他成員參與代碼審核
前提條件
1.作為評審者,我們需要對項目的需求和設計文檔有充分的了解,以便更好地理解代碼的目的和實現方式。
2.評審者需要對評審的代碼負責,而不是不看直接merge通過之類。
注意事項
1.有時候一個代碼審核者無法覆蓋整個CL,因為其中可能包含太多的代碼文件或者需要不同的技術背景來理解。在這種情況下,我們需要多位審核者參與審核,以確保能夠覆蓋所有的代碼文件。我們應該考慮使用多個審核者來互相檢查和驗證代碼質量,從而減少潛在的錯誤和漏洞。
2.不建議剛加入團隊成員不足3個月并且還不熟悉業務的新人,具體可根據團隊情況考慮。
2、評審的方式有哪些?
1.線上Coding平臺(占比90%):這種方式優點是京Me自動通知方便快捷,可以節省時間和成本。但是需要注意的是,由于Coding平臺缺乏Idea其他內容上下文,前期評審者可能不太習慣,需要慢慢適應。
2.線下評審
1.面對面審核(占比5%):適合改動較小,這種方式的優點是有疑問時可以隨時提問并得到解答,可以直接了解開發者的思路和意圖,有助于發現更深層次的問題。但是需要注意的是,這種方式需要耗費較多的時間和精力。
2.團隊組會審批(占比5%):對于大型項目需求或者黃金核心鏈路有風險的需求,除了線上評審外,我們可以線下再次Review把控。線下的核心是把控上線風險點(Joyspace列出相關事項),通過團隊內部的討論和協作來提高代碼質量。這種方式的優點是可以充分發揮團隊的力量,共同解決潛在問題。但是需要注意的是,由于參與人數較多,可能需要較長的時間來完成評審過程。Promise遇到牽扯較大、核心鏈路風險高的需求會采用線下Review風險事宜。
總之,在選擇代碼審核方式時,我們應該根據具體情況進行選擇。同時,我們也應該注意及時反饋評審結果和建議,以便開發者能夠及時修正問題并提高代碼質量。
3、CR的標準是什么?
代碼審核的目的是保證持續改進代碼庫質量。
1.原則上,如果提交的代碼能顯著提高質量,即使不完美也批準。
2.審核者應分享知識,寫一些有助于學習的評論。
3.涉及設計的問題應基于原則權衡,而非個人喜好。
4.如果沒有規則,讓作者與現有代碼保持一致,不惡化系統質量。
4、代碼審核步驟有哪些?
1.全面了解 CL背后(需求、技術改造)。這個 CL 是否有意義?它是否包含好的描述?
2.綜觀整個 CL 中最重要的部分。從整體來看,設計是否合理?
1.找到包含 CL “主體”部分的文件。通常,如果一個文件包含大量的邏輯修改,那么它就是 CL 的主體部分。先審視這些主體部分有助于為其他部分理出上下文。如果 CL 太大,很難找到主體部分的位置,可以征詢開發者的建議,你應該先看哪些部分,并建議他把一個CL拆分多個小CL,小步快跑(功能獨立的可設置為一個小CL。比如web頁面操作的分為一個小CL,定時任務Task相關的是一個小CL,API接口部分是一個小CL)
2.如果發現CL 中有一些重要的設計缺陷或設計問題,立即給出反饋,即使現在還沒來得及審核其他部分。實際上,審核其他部分很有可能是浪費時間。只要這個設計問題足夠大,在重新設計時,其他代碼很有可能會消失或變得無關緊要了。
3.以合適的順序檢查CL的其他部分。在確認 CL 沒有重要設計問題之后,整理出審視文件的順序,并確保不會遺漏任何文件。通常,在審視了主要文件之后,最簡單的方式就是按照代碼審核工具呈現出來的順序遍歷每個文件。有時候,先閱讀測試代碼更有幫助,因為看了測試代碼之后,你就明白這個 CL 的期望行為是什么。
5、代碼審核者應該關注哪些?
確保審核了每行代碼,并且查看上下文,確保你正在提升代碼質量,當開發者的 CL 中包含好東西時,稱贊他們。
5.1、兼容性
審核者需要判斷,本次CL是否會影響線上現有功能
1.比如JSF接口出參的位置,是否會導致上游調用序列化出錯?
2.中間件配置變更,比如數據表增加索引,表數據量多大,會不會增加索引導致數據庫阻塞?
3.是否需要增加Ducc開關技術,在穩定性和代碼復雜性中均衡考量
5.2、設計
1.審核一個 CL 最重要的事情就是考慮它的整體設計,代碼是否按照架構設計方案進行編碼?
2.API & DataBase 是否合理
3.這段代碼應該放到哪里更合適?它是否可以很好地與系統其他部分集成?
4.還應關注:技術棧簡單、統一的控制,避免非必要引入三方框架、組件等,為系統穩定性埋下隱患
5.3、功能
1.這個 CL 所實現的功能與需求期望開發的功能是一致的嗎?
2.絕大多數情況,我們期望開發者在提交 CL 進行審核之前,已經做過充分的測試。但作為審核者,在審核代碼時仍要考慮邊界情況、并發問題等等。確保消滅那些通過閱讀代碼就能發現的缺陷。
3.作為審核者,你可以根據需要親自驗證 CL 的功能。僅通過閱讀代碼,你很難理解有哪些改變,對系統有哪些影響。對于這種修改,可以讓開發者演示這個功能。當然,如果方便把 CL 的代碼集成到你的開發環境,你也可以自己親自嘗試。
4.在代碼審核過程中,對功能的考慮還包含一種重要場景:CL 中包含一些“并行計算”,可能會帶來死鎖或競爭條件。運行代碼一般很難發現這類問題,通常需要(開發者和審核者)仔細考慮,以確保不會引入新的問題。(這也是不要引入并發模型的一個好理由,因為它可能引入死鎖或競爭條件,同時也增加了代碼審核和代碼理解的難度。)
5.4、性能
1.這段代碼如果數據量大,性能是否有問題?有沒有更好的實現方式?
案例:多個for循環無用業務
5.5、復雜性
1.是不是 CL 可以不必這么復雜?在 CL 的每個層次上檢查——哪一行或哪幾行是不是太復雜了?功能是否太復雜了?類(class)是否太復雜了?“太復雜”的定義是代碼閱讀者不易快速理解。同時意味著以后其他開發者調用或修改它時,很容易引入新的缺陷。
2.另一種類型的復雜是過度工程化(也稱為過度設計)。開發者在設計代碼時太過于在意它的通用性,或在系統中加入了目前不需要的功能。審核者應該特別警惕過度工程化。鼓勵開發者解決 當前 應該解決的問題,而不是開發者推測將來 可能 需要解決的問題。將來的問題,等碰到的時候,你才能看到它的實際需求和具體情況,到那時再解決也不遲。
5.6、日志
日志打印是否簡明扼要,是否有助于線上問題排查;關鍵環節是否打印了日志
5.7、異常
異常處理,是否符合服務可用率治理規范,確保增量代碼不腐化已經通過可用率星級認證的接口;
5.8、測試
1.同時要求開發者提供 CL 對應的單元測試。單測代碼與開發代碼應放到同一個 CL 中,除非碰到緊急情況
2.確保 CL 中的測試是正確的、明智的、有用的。測試代碼并不是用來測試其自身,我們很少為測試代碼寫測試代碼——這就要求我們確保測試代碼是正確的。
3.當代碼出問題時,是否測試會運行失敗?如果代碼改變了,是否會產生誤報?是否每個測試都使用了簡單有用的斷言?不同的測試方式是否做了合適的拆分?
謹記:測試代碼也是需要維護的代碼。不要因為不會編譯打包到最終的產品中,就接受復雜的測試代碼。
5.9、每行代碼
1.在審核代碼時,仔細檢查每行 代碼。某些文件,如數據文件、生成的set、get代碼或較大的數據結構,可以一掃而過。但是人寫的代碼,如類、功能或代碼塊不能一目十行,我們不應假設它是正確的。有些代碼得尤其小心——這需要你自己權衡——至少你應該確認你 理解 這些代碼在做什么。
2.如果代碼很難讀懂,那就放慢審核速度,告訴開發者你沒讀懂代碼,讓他解釋與澄清,之后繼續審核。如果你讀不懂代碼,很有可能其他工程師也不懂。實際上,這么做也是在幫助以后的工程師,當他讀到這段代碼時更容易理解代碼。所以,讓開發者解釋清楚。
如果你理解這些代碼,但是感覺自己不夠資格審核它,確保找到一個夠資格的人來審核,尤其是比較復雜的問題,如安全、并發、可訪問性等等。
5.10、上下文
1.把 CL 放到一個更廣的上下文中來看,通常很有用。在審核工具中,我們往往只能看到開發者修改的那部分代碼。更多時候從整個文件的角度來讀代碼才有意義。例如,有時候你只看到添加了幾行代碼,但從整個文件來看,你發現這幾行代碼添加到了一個100行的方法中。在增加之后,需要把它拆分成更小的方法。
2.把 CL 放到系統的上下文中來考慮也很有用。CL 能提升系統的代碼健康狀況,還是讓系統變得更復雜、更難測試?大多數系統變得很復雜都是由每個細小的復雜累積而成的,在提交每個 CL 時都應避免讓代碼變得復雜。
5.11、文檔
1.如果 CL 修改了編譯、測試、交互、發布的方式,那么應檢查下相關的文檔是否也更新了,如 README 文件、CF頁面,或其他所有生成的參考文檔。
2.如果 CL 刪除或棄用(deprecate)了一些代碼,考慮是否也應刪除相應的文檔。如果沒有這些文檔,讓開發者( CL 提交者)提供。
5.12、注釋
1.開發者是否寫了清晰的注釋?是否所有的注釋都是必須的?通常當注釋解釋為什么這些代碼應該存在時,它才是必須的,而不是解釋這些代碼做什么。如果代碼邏輯不清晰,讓人看不懂,那么應該重寫,讓它變得更簡單。當然,也有例外(例如正則表達式和復雜的算法通常需要注釋來說明),但大部分注釋應該提供代碼本身沒有提供的信息,如這么做背后的原因是什么。
2.有時候也應該看一下這個 CL 相關的歷史注釋。例如,以前寫的TODO,現在可以刪掉了;某段代碼修改了,其注釋也應隨之修改。
注意,注釋與類、模塊、功能的文檔是不同的,這類文檔應該描述代碼的功能,怎樣被調用,以及被調用時它的行為是什么。
5.13、代碼樣式
1.在京東,我們所有的主要編程語言都要遵循京東代碼規范,確保 CL 遵守代碼樣式指南中的建議。
2.如果發現某些樣式在代碼樣式指南中并未提及,在注釋中加上“Nit”,讓開發者知道,這是一個小瑕疵,他可以按照你的建議去做,但這不是必須的。不要因為個人的樣式偏好而導致 CL 延遲提交。
3.作者在提交 CL 時,代碼中不應包含較大的樣式改變。為這樣很難比較出 CL 中有哪些代碼修改,其后的代碼合并、回滾會變得更困難,容易產生問題。如果作者想重新格式化文件,應該把代碼格式化作為單獨的 CL 先提交,之后再提交包含功能的 CL
5.15、好的方面
如果在 CL 中看到一些比較好的方面,告訴開發者,尤其是當你在審核代碼時添加了評論,他在回復你的評論,嘗試向你解釋的時候。審核者往往只關注代碼中的錯誤,他們也應該對開發者的優秀實踐表示鼓勵和感謝。有時候,告訴開發者他們在哪些方面做得很好,比告訴他們在哪些方面做得不足更有價值。
6、怎樣寫代碼審核的評論?
1.禮貌,保持友善
2.解釋原因:闡明你的意圖、你正在遵循的最佳實踐、你在提升代碼健康程度
3.給出明確的信息,指出問題所在,讓開發者最后做決定。
4.鼓勵開發者簡化代碼,給代碼添加注釋,而不是向你解釋為什么這么復雜
7、代碼評論被拒絕,應如何處理?
1.開發者和審核者都可能對代碼提出修改建議,但應先考慮開發者是否正確。若開發者正確,可忽略評論;否則,審核者需解釋建議必要性。
2.若審核者堅持修改,即使需額外工作也值得,因為提升質量是持續過程。
3.有時需多輪解釋,保持禮貌。
4.常見拒絕原因是想盡快完成,建議現在就開始清理,或分配給自己 bug 以避免遺忘,加上 TODO 注釋和 bug 編號。
四、代碼開發者指南
從開發者的角度來看,我們也需要了解一些開發者的指南。這些指南包括:
1.遵循編碼規范和最佳實踐,編寫良好的CL描述:作為開發者,我們應該遵循編碼規范和最佳實踐,確保代碼的質量和可讀性。
2.CL提交的原子性,如何定義小CL?
3.如何處理審核者評論及修改代碼?
本文包含開發者怎樣讓代碼審核容易通過的最佳實踐。在讀完本指南后,相信能夠讓你的審核質量更高,速度更快。
1、編寫良好的 CL 描述
CL 描述內容應該提供足夠的信息,讓CR更加清晰。它包含了改了什么 與 為什么 這么修改?
1.1、良好的 CL 描述
附Promise這個CL,清晰描述了需求PRD(鏈接),及核心邏輯,DUCC開關及單測描述
1.2、糟糕的 CL 描述
“修復 bug”是一個很不恰當的描述。哪個 bug ?你做了哪些事情來修復它?通通都沒有。類似糟糕的描述還包括:“增加補丁”,“刪除代碼”,“沒有描述”
2、原子性提交
《持續交付 2.0》的四大工作原則是:堅持少做、持續分解問題、堅持快速反饋和持續改進并衡量。這些原則可以不斷縮短持續交付“8”字環的運行周期,提升用戶反饋速度,從而提高業務的敏捷性。它們在代碼提交與 Code Review 中的應用就是:提交的原子性。
2.1、為什么應該寫小 CL?
小 CL 有如下優點:
1.評審效率更高:將大段的CL拆分成多個小段CL。這樣可以讓評審者更容易集中幾分鐘(5分鐘比30分鐘容易)在關鍵部分,提高評審效率。
2.反饋更及時:如果開發者花費了很大的精力開發了一個大 CL,直到審核的時候才知道整個開發的方向錯了,那么之前的所有時間就全浪費了。
3.引入新缺陷概率更低: 如果修改的內容比較少,自然審核人的效率會更高,開發者與審核者都更容易判斷是否引入了新的缺陷。
4.更易于設計:完善小 CL 的設計和修改要容易得多,多次微小的代碼質量提高比一次大的設計改變更容易。
5.更容易合并代碼:大 CL 在合并代碼時會花費很長的時間,在合并時需要花費大量時間,而且在寫 CL 期間可能不得不頻繁地合并。
6.更容易回退:一個大 CL 開發的時間比較長,這意味從開發到代碼提交這段期間,代碼文件的變更會比較多。當回退代碼時,情況會變得很復雜,因為所有中間的 CL 很有可能也需要回退。
請注意:審核者有權因為你的 CL 太大而拒絕它。
2.2、那么如何定義“小”?
一般而言,一個 CL 的大小就應該是獨立功能的修改。這意味著:
1.盡量將一個CL的大小最小化,它只做一件事。每個CL應該只關注一個特定的功能或任務,而不是整個功能。這樣可以使審核者更容易理解和評估CL的內容,并減少不必要的復雜性和混亂。可與審核者進行討論,以確定CL的適當大小??梢怨餐接慍L是否涵蓋了足夠的功能,并且能夠提供足夠的上下文來理解CL的目的和影響。通過溝通和合作,可以找到最佳的平衡點。
2.確保CL中包含了所有必要的信息,以便審核者可以理解CL的目的和內容。除了CL本身的代碼之外,還應包括對CL的描述、已存在的代碼或之前已經審核過的相關CL的信息。這樣審核者可以更好地了解CL的背景和上下文,從而做出準確的判斷。
3.在提交CL之后,確保系統仍然能夠正常運行。無論是對于用戶還是開發人員來說,系統的正常運行是至關重要的。因此,在編寫CL時,請確保不會引入任何破壞性或不兼容的更改。
4.如果代碼難以理解,可能是因為CL的大小還不夠小。如果需要添加一個新的API,最好將其與相應的使用方法一起包含在同一個CL中。這樣可以方便審核者理解如何使用該API,同時也方便后續的開發者使用和維護。此外,這還可以有效防止提交的API無人使用的情況發生。
5.定期回顧和改進您的CL過程。通過反思和總結經驗教訓,您可以找到可能存在的問題和改進的空間。持續優化您的CL過程將有助于提高整體的開發效率和代碼質量。
沒有直觀的標準判斷 CL “太大”應該符合哪些條件。
2.3、什么時候可以有大 CL?
當然,也有一些例外情形,允許 CL 比較大:
?刪除一個文件與修改一行沒有太大區別, 因為它不會花費審核者太多時間。
?有時候,一個大 CL 可能是由可靠的自動代碼重構工具生成的,審核者的工作主要是檢查它是否做了它應該做的工作。雖然符合以上提到的注意事項(例如合并和測試),這類 CL 也可能比較大。
2.4、注意事項
1.CL之前研發通過插件(idea集成JoyCoder,京東Idea插件、sonar等檢查語法之類)檢查并且修復各種代碼樣式問題。
2.把系統重構及技術改造的單獨CL
3.把測試代碼包含到對應功能的 CL中
4.不要破壞編譯,影響他人
3、如何處理審核者的評論
在發出 CL 之后,審核者一般會給出反饋(評論),讓你修改代碼。以下是一些建議,可以幫助您在代碼審核過程中處理審核者的評論:
3.1、保持好心態
1.先思考自己是否有改進的空間。仔細考慮審核者是否在反饋中提供了有價值的內容,可以幫助提高代碼庫的質量。你的第一個問題應該永遠都是,“審核者說得對嗎?” 如果確認你是對的,那就解釋為什么你的方法比較好。
2.保持冷靜和專業。無論審核者的評論是正面的還是負面的,都要保持冷靜和專業的態度。不要將審核者的評論視為個人攻擊或人身攻擊,而是將其視為對您工作質量和代碼庫質量的建議和改進的機會。
3.從建設性的角度去理解評論。審核者可能以批判性的語氣表達他們的評論,但作為開發者,您應該努力從中尋找建設性的意見和建議。問問自己,“我能從這個評論中學到什么?如何改進我的代碼?”然后根據這些建議來調整和改進您的代碼。
4.不要帶著情緒回復評論。在代碼審核過程中,違反專業禮儀是非常嚴重的事情。如果您感到生氣、惱火或受到冒犯,最好先離開電腦一會兒,或者做其他事情來平靜自己的情緒。確保您可以以禮貌和友好的方式回復審核者的評論。
5.尊重審核者的專業知識和經驗。審核者通常具有豐富的編程經驗和專業知識,他們的意見和反饋對于提高您的代碼質量和產品的質量非常重要。尊重他們的專業意見,并盡可能采納他們的建議進行改進。
6.尋求澄清或進一步解釋。如果您對審核者的評論有任何疑問或不理解的地方,不要猶豫向他們尋求澄清或進一步的解釋。這有助于消除任何誤解,并確保您正確理解了對方的意見和建議。
7.提供適當的回應。在回復審核者的評論時,盡量提供有建設性的回答和解決方案。如果您不同意對方的觀點,可以提出您的理由并提出相應的解決方案。避免爭論或陷入無意義的爭論中。
8.接受批評并持續改進。審核者的評論可能是為了幫助您改進自己的工作和代碼庫的質量。接受批評,并將其視為一個學習和成長的機會。通過持續改進和修正錯誤,您可以提升自己的編碼能力和產品質量。
3.2、修復代碼
1.澄清代碼本身。當審核者表示對您的代碼中的某些內容不理解時,首先嘗試以清晰和簡潔的方式澄清代碼的目的和功能。確保您能夠用簡單明了的語言解釋代碼的邏輯和實現方式。
2.添加注釋來解釋代碼。如果無法通過澄清代碼本身來解決審核者的疑問,您可以添加適當的注釋來解釋為什么這段代碼這樣寫。注釋應該簡明扼要地概括代碼的功能、目的和關鍵步驟,以便其他開發者能夠更好地理解和維護代碼。
3.清理和重構。如果審核者無法理解某段代碼,很有可能其他的代碼閱讀者也會遇到相同的困惑。在這種情況下,考慮對代碼進行清理和重構,以提高其可讀性和可維護性。刪除不必要的復雜性,使用清晰的命名約定和適當的代碼結構,以幫助其他開發者更容易理解和閱讀代碼。
4.鼓勵開放的溝通和討論。在處理審核者的不理解時,保持開放和積極的溝通態度非常重要。與審核者一起探討問題的根源,尋求共同的解決方案,并盡可能提供清晰的解釋和支持。這種開放的溝通有助于建立信任和合作,推動問題的解決和改進的進程。
五、代碼評審的沖突解決
以下是一些建議,可以幫助您在與審核者之間出現沖突時進行有效的溝通和解決:
1.強調代碼的重要性。在與審核者討論問題時,始終強調代碼的重要性和正確性。指出代碼是解決問題的關鍵,而不是個人攻擊或人身攻擊的借口。
2.嘗試達成共識。首先,努力與審核者達成共識并找到雙方都可以接受的解決方案。這可能涉及妥協、解釋各自的觀點和理解對方的立場。通過開放和建設性的討論,尋找共同的目標和原則。
3.參考代碼規范和CR標準。如果無法達成共識,可以參考代碼規范和CR標準等文檔來提供指導和準則。這些文檔通常包含最佳實踐、編碼規范和代碼審查要求,可以作為解決沖突的參考依據。
4.面對面溝通。當面臨無法解決的問題時,考慮面對面與審核者進行溝通。面對面的會議可以提供更多的上下文和細節,有助于更好地理解彼此的觀點,并更有效地解決問題。確保在會議之后記錄下討論的結果,并在代碼審核評論中進行反饋。
5.尋求團隊的支持和意見。如果面對面的溝通仍然無法解決問題,可以尋求其他團隊成員(如架構師、TL)的意見和支持。他們可能能夠提供不同的視角和解決方案,幫助您更好地處理沖突。讓TL參與討論并做出最終決定,以確保問題得到適當的解決和跟進。
6.保持專業和尊重的態度。無論遇到什么情況,都要保持專業和尊重的態度對待審核者和整個團隊。避免爭吵、指責或情緒化的反應,而是以理性和冷靜的方式處理沖突,并致力于找到最佳的解決方案。
六、緊急情況
以下是一些建議,可以幫助您處理緊急的CL和相關的代碼審核流程:
1.快速響應并加快審核流程。在緊急情況下,審核者應該優先考慮代碼的正確性和解決緊急問題的能力,盡快回復審核者的請求,并盡力加快審核流程。這可能包括加快代碼評審、測試和驗證的速度,以及與團隊成員協調解決問題的時間。
2.完成緊急情況后進行更全面的審核。一旦緊急情況處理完畢,您可以回過頭來進行一次更全面的代碼審核。這次審核可以檢查代碼的整體質量和一致性,并確保所有的功能和修復都按照最佳實踐進行編寫和維護。
3.記錄和總結經驗教訓。緊急情況發生后,及時記錄下您的處理過程和經驗教訓?;仡欉@些經驗可以幫助您改進未來的應對策略,并為類似的情況提供參考依據。
七、CodeReview-AI大模型
1.上面描寫的都是人去CodeReview,但靠人力太費事費力,而且團隊每個人的水平不一樣,這樣也會導致CR的效果也不一樣。所以我們需要思考如何利用科技的力量,比如大模型等工具去CodeReview,通過定義好的代碼規范和代碼比對,給出建議等,提升代碼效率的同時也保障了代碼質量。
八、總結
總之,在進行代碼評審時,我們需要從評審者和開發者的不同角度出發,關注不同的方面。通過合理的評審和開發指南,提高代碼質量和團隊協作效率。上面描述的方式還需要大家在實踐過程中進行持續改進,并根據團隊的實際情況進行調整:
1.考慮團隊的特點和需求。每個團隊都有自己獨特的特點和需求。在制定代碼審查方法和流程時,要充分考慮團隊的規模、項目類型、開發語言和技術棧等因素。確保所選的方法和流程與團隊的實際情況相適應。
2.定期回顧和改進。代碼審查是一個持續不斷的過程,需要定期回顧和改進。定期與團隊成員討論和評估當前的代碼審查方法和流程,了解他們的體驗和意見。根據反饋和經驗教訓進行必要的調整和改進。
3.培養學習氛圍和文化。代碼審查不僅是為了解決問題和提升代碼質量,也是一個學習和成長的機會。鼓勵團隊成員互相支持、分享知識和經驗,并建立一種積極進取的學習文化。通過培訓、分享會和團隊活動等方式來促進學習和知識傳遞。
4.保持持續改進的動力。代碼審查是一個長期而持續的過程,需要不斷努力和改進。保持對代碼質量的關注和追求卓越的動力,將代碼審查視為一個持續改進的機會,并不斷尋求提高團隊整體代碼水平的方法。
本文旨在為大家提供參考和借鑒。同時也歡迎大家對文章進行指正和建議,以便更好地完善我們的實踐經驗。如果您有更好的實踐經驗,也歡迎與我們交流分享。謝謝!
參考文獻:
Google Engineering Practices Documentation
谷歌代碼審查指南 譯文:https://jimmysong.io/eng-practices/docs/review/
審核編輯 黃宇
-
Code
+關注
關注
0文章
68瀏覽量
15371
發布評論請先 登錄
相關推薦
評論