精品国产人成在线_亚洲高清无码在线观看_国产在线视频国产永久2021_国产AV综合第一页一个的一区免费影院黑人_最近中文字幕MV高清在线视频

0
  • 聊天消息
  • 系統消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術視頻
  • 寫文章/發帖/加入社區
會員中心
創作中心

完善資料讓更多小伙伴認識你,還能領取20積分哦,立即完善>

3天內不再提示

Code Review:探索工程實踐之道

京東云 ? 來源:京東物流 馮志文 ? 作者:京東物流 馮志文 ? 2024-10-11 14:43 ? 次閱讀

作者:京東物流 馮志文

前言

本文參考《京東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輪,第一次是提測前,最后一輪是上線前。每一輪的側重點不一樣。流程如下:

wKgaoWcIyQeAXD10AAYnLKNf7jI880.png


備注: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
收藏 人收藏

    評論

    相關推薦

    芯盾時代榮獲2024金融科技應用場景大賽“探索實踐獎”

    的“AI 智能反欺詐風控解決方案”憑借領先的技術水平、突出的應用效果,從眾多參賽項目中脫穎而出,榮獲“探索實踐獎”。
    的頭像 發表于 11-09 10:12 ?341次閱讀

    本源量子榮獲2024金融科技場景應用大賽“探索實踐獎”

    應用大賽“探索實踐獎”。圖為2024金融科技場景應用大賽“探索實踐獎”獲獎證書與獎杯此次獲獎的方案——基于變分量子線路投資組合優化真機應用已上線本源量子官網,該應用利
    的頭像 發表于 10-23 08:05 ?257次閱讀
    本源量子榮獲2024金融科技場景應用大賽“<b class='flag-5'>探索</b><b class='flag-5'>實踐</b>獎”

    如何將CCS 3.x工程遷移至最新的Code Composer Studio? (CCS)

    電子發燒友網站提供《如何將CCS 3.x工程遷移至最新的Code Composer Studio? (CCS).pdf》資料免費下載
    發表于 09-21 09:28 ?0次下載
    如何將CCS 3.x<b class='flag-5'>工程</b>遷移至最新的<b class='flag-5'>Code</b> Composer Studio? (CCS)

    Autobots應用探索實踐中的思考與發現

    了; 背景2:作為XXX共建項目的成員之一同時也是第一批用戶,我用它做了幾個測試實踐,和大佬們一起探討交流。 實踐一,快速搜索需求文檔 模糊搜索 這個場景多數用于我們不清楚自己到底要找的是哪個需求文檔了,可能只是大概對需求文檔有個印象,我們可以從返
    的頭像 發表于 07-16 15:00 ?235次閱讀
    Autobots應用<b class='flag-5'>探索</b>:<b class='flag-5'>實踐</b>中的思考與發現

    振弦采集儀的工程安全監測實踐與案例分析

    振弦采集儀的工程安全監測實踐與案例分析 振弦采集儀是一種常用的工程安全監測儀器,通過測量被監測結構的振動頻率與振型,可以實時監測結構的安全狀況。本文將結合實踐經驗和案例分析,探討振弦采
    的頭像 發表于 07-01 11:01 ?211次閱讀
    振弦采集儀的<b class='flag-5'>工程</b>安全監測<b class='flag-5'>實踐</b>與案例分析

    【大語言模型:原理與工程實踐探索《大語言模型原理與工程實踐》2.0

    《大語言模型“原理與工程實踐”》是關于大語言模型內在機理和應用實踐的一次深入探索。作者不僅深入討論了理論,還提供了豐富的實踐案例,幫助讀者理
    發表于 05-07 10:30

    【大語言模型:原理與工程實踐探索《大語言模型原理與工程實踐

    的未來發展方向進行了展望,包括跨領域、跨模態和自動提示生成能力方向,為讀者提供了對未來技術發展的深刻見解?!洞笳Z言模型原理與工程實踐》是一本內容豐富、深入淺出的技術書籍。它不僅為讀者提供了大語言模型
    發表于 04-30 15:35

    EMI電磁干擾:EMI電磁干擾的識別與解決之道

    深圳比創達EMC|EMI電磁干擾:EMI電磁干擾的識別與解決之道
    的頭像 發表于 04-25 11:17 ?776次閱讀
    EMI電磁干擾:EMI電磁干擾的識別與解決<b class='flag-5'>之道</b>

    云原生轉型中從理念到實踐探索與挑戰

    :運營商從理念到實踐探索與挑戰”的主題演講,分享了廣東移動與華為公司在云原生轉型過程中合作探索實踐及關鍵成果。
    的頭像 發表于 04-23 11:45 ?426次閱讀

    訊維融合通信系統在金融數據中心建設的實踐探索

    訊維融合通信系統在金融數據中心建設的實踐探索中,展現出了其獨特的技術優勢和應用價值。以下是對這一實踐探索的詳細分析: 首先,金融數據中心作為金融機構的核心信息樞紐,對通信系統的可靠性、
    的頭像 發表于 04-18 15:41 ?295次閱讀

    振弦采集儀在橋梁工程監測中的優勢與實踐案例

    振弦采集儀在橋梁工程監測中的優勢與實踐案例 在橋梁工程監測中,振弦采集儀是一種常用的監測設備。它的主要功能是通過采集橋梁振動信號,實時監測橋梁的結構健康狀態。與傳統的監測方法相比,振弦采集儀具有一些
    的頭像 發表于 04-01 14:03 ?256次閱讀
    振弦采集儀在橋梁<b class='flag-5'>工程</b>監測中的優勢與<b class='flag-5'>實踐</b>案例

    淺談配電室智能監控系統的設計與實踐探索

    淺談配電室智能監控系統的設計與實踐探索 張穎姣 安科瑞電氣股份有限公司 上海嘉定201801 摘要:配電室智能監控系統可以運用計算機技術將配電工程的各個環節有機結合起來,全面控制配電系統工作狀態
    的頭像 發表于 02-19 14:16 ?482次閱讀
    淺談配電室智能監控系統的設計與<b class='flag-5'>實踐</b><b class='flag-5'>探索</b>

    淺析配電室智能監控系統的設計與實踐探索

    淺析配電室智能監控系統的設計與實踐探索 張穎姣 安科瑞電氣股份有限公司 上海嘉定 201801 摘要:配電室智能監控系統設計,引起供電部門重視,借助科學技術,加大配電室智能監控系統設計創新力度,改變
    的頭像 發表于 02-19 14:12 ?397次閱讀
    淺析配電室智能監控系統的設計與<b class='flag-5'>實踐</b><b class='flag-5'>探索</b>

    基于振弦采集儀的工程監測技術探索

    基于振弦采集儀的工程監測技術探索 隨著工程建設的日益發展,對工程監測的需求也越來越迫切。工程監測是保障
    的頭像 發表于 12-19 14:54 ?334次閱讀
    基于振弦采集儀的<b class='flag-5'>工程</b>監測技術<b class='flag-5'>探索</b>

    振弦采集儀在巖土工程中的探索與應用

    振弦采集儀在巖土工程中的探索與應用 振弦采集儀是一種常用的測量儀器,在巖土工程中具有重要的應用價值。它主要利用振弦原理,通過測量振動信號的特征參數來分析地下土體的力學特性以及工程中的變
    的頭像 發表于 12-08 13:57 ?402次閱讀
    振弦采集儀在巖土<b class='flag-5'>工程</b>中的<b class='flag-5'>探索</b>與應用