我在您的帖子中註意到可能與這種情況有關的事情：

• 您是團隊的最高審核者
• 您還是最資深的團隊之一成員
• 基於生產的代碼來監視您的個人生產力

因此

• 您的團隊可能會忘記他們需要編寫代碼進行評論，因為您做了很多事情
• 您的團隊可能會認為他們沒有“判斷”您所需的技能
• 您的團隊可能會認為他們必須重點關注或確定優先級

您不應該害怕要求您的同事進行審查，並且出於潛在的原因，他們不審查您的代碼。我的方法是與小型委員會或一對一的同事進行對話，因為我覺得在那裡會更容易誠實，但是您也可以在會議中提出要求，例如回顧等。由於您擁有指標，因此您可以要求評論最少的人，並放心事實既簡單又令人讚賞。

最終，在您向人們問了幾次之後，他們會養成良好的習慣，即自己查看評論並進行評論。我們經常在聊天中對自己進行ping操作以獲取待審核的評論，並且現在的負載已經相當均衡了。

我認為這裡的問題是，每個團隊成員都應該交付自己的工作，而不是擁有共同的交付目標。

如果每個工程師都有自己的代碼來編寫和交付，並且以實現此目標（而不是實現團隊目標）為衡量標準，那麼當然也沒有動力去審查其他人的代碼更改。

我不確定您作為一個人可以做什麼但是，確實需要更改它–需要從組織的角度（即您的經理，產品所有者或類似人員）著手。團隊需要在最重要的方面確定明確的優先級，然後這些交付位需要在處理其他代碼之前，請先進行審核。

轉到同事的辦公桌，詢問他們是否可以進行代碼檢查。對於簡短的人，他們很可能會同意，對於較長的人，他們可能會要求以後做，請趁機指定一個時間段進行審核。

如果您確實需要，您可以正式設置會議，既可以確保進行代碼審查，又可以防止您或您的審查者被其他人打擾，這對您很有用。

首先，不要將缺乏代碼審查的內在影響視為您的團隊遇到的問題。似乎您在考慮缺少代碼審查是對您的個人偏見，而事實並非如此。有時人們很忙，或者他們看不到檢查代碼的好處。這不是攻擊。

第二，如果您發現需要進行代碼審查並且團隊沒有花時間，請與您的經理聯繫。我工作過的幾個地方每週都有固定的時間進行代碼審查，我們將淘汰一些更關鍵的小組，以進行更大或更高級的更改。如果規模較小，我們可以在時間表允許的情況下成對審核。但是我們絕不允許未經審查就合併代碼。實行。對於某些經理來說，代碼審查並不重要，直到他們看到它可以改善底線為止。

不是您，而是團隊文化。通過繞過代碼審查，團隊沒有遵循軟件工程的實踐，也不了解它們為什麼如此重要。這是一個關鍵問題，需要盡快進行更改。這些問題需要解決：

• 為什麼如此重要。
• 對於誰？誰應該做？我要澄清的是，代碼審查不僅應由老年人進行，而且老年人還需要對其代碼進行審查。我見過一些團隊介紹了git實施規則，例如需要兩個審閱者的保護分支。
• 如何編寫審閱代碼以及如何提供適當的反饋。

期望應該明確。這些要點必須提交給團隊（例如，會議，&學習午餐）。變革很難，要做好準備並尋求盟友。

對我有用的是明確指定某人進行審核。在我們當前的項目中，我們甚至將JIRA中的問題重新分配給審閱者。如果您不能將其分配給其他人，請將其分配給可以的人（項目經理）。無關緊要的是該人實際進行了審核，而是該人認真地完成了審核。

分配一個特定的人員意味著，這可以追溯到該人員的工作。我發現即使對於無論如何都會進行最多審查的我來說，如果將審查任務分配給我也有幫助-它清楚地表明任務處於待審查狀態，並且進度現在被我阻止了/我現在負責任。

我的處境非常相似。有素質的人，有稱讚的經理，一絲不苟的照顧交付，與工作以外的人保持良好的關係。有一天，我們團隊中的一個新人告訴我，他聽說我是一個坑，但每個人都愛我。誠實的360度反饋。 ：）

然後我意識到，我非常追求完美，以人為本是我的第二要務。仍然是重中之重，我為人民做了一切，除了犧牲質量。

人們感覺到了。即使我沒有意識，我還是走高了，就像質量是我的第二名。我意識到這會使人感到次要或自卑。生活改善了很多，人們建立了許多新技能，團隊也變得很棒，素質很強而且很穩定。幫助。

共識

如果您的團隊不同意代碼審查的價值，則無法讓團隊成員審查您的代碼。我想說代碼審查是大多數開發人員做不到的三件事之一。因此，第一步是在與整個團隊（包括經理）的會議中簡單地討論代碼審查。詢問他們對它的看法，它是否有價值，以及應該多久完成一次。

我敢打賭，至少有一半人認為這是浪費時間。如果是這樣，那麼您的第一步就是教育。您需要在做出有價值評論的地方進行評論，特別是如果有人在合併之前發現了一個實際的錯誤（您不應該將CR作為發現錯誤的工具出售，但是當它發生時這是一個很好的獎勵）。如果您的同事缺乏經驗，這可能很難。即使這樣，您也應該盡可能經常地提出一些建議，以便他們最終吸收CR->更好的質量->更好的代碼->更少的錯誤->更好的開發人員生活質量的想法。

強制執行

一旦您讓團隊至少對CR有價值的想法輕描淡寫，那麼您就需要製定一種實施它的機制。理想情況下，您的版本控制系統可以執行此操作（例如，在GitHub上進行配置很簡單）。如果沒有人可以在沒有CR的情況下合併，那麼希望所有人成為瓶頸，因此可以激勵他們清除積壓的積壓。發生這種情況時，您需要做一些起初看起來對您來說非常困難的事情：您無需執行任何操作。每個開發人員平均產生PR數量，因此每個開發人員都需要執行該數量的CR，以平均分配工作。您需要估計該數目，並且最多不要超過CR。

很快，團隊中的每個人都會抱怨有大量的PR等待合併，您需要明確說明整個團隊都需要承擔對其進行審查的工作。輕輕地提醒他們，他們同意該值，並拒絕進行任何刪除合併中CR鎖定的調用。他們很可能偶爾會偶爾進行CR。為了幫助分配問責制，我為團隊創建了一個工具，該工具對開發人員進行了非常基本的PR循環分配。每個人都可以看到誰沒有進行審核，並且每個人都知道如果他們的PR在審核中被阻止，該與誰交談。擁有這種可見性可以幫助強制執行所需的行為。

而且，資歷與這種現象確實無關。我看到了所有技能水平的開發人員。很多時候，在現代軟件文化中成長的初級開發人員會接受代碼審查，而習慣於合併而無需審查的高級開發人員會拒絕它。因此，實際上，這只是個人的喜好，不幸的是，這種喜好在整個行業中普遍存在。代碼審查應該主要是關於知識的分發。僅僅讓別人閱讀您的更改，就可以使團隊中的另一個人意識到更改，並且更有可能使團隊注意到與同時發生或即將發生的更改潛在的設計衝突。也用於教育。初級開發者應該從執行中獲得與老年人一樣多的CR，但是性質不同。您應該告訴大三學生，如果他們對他們正在審查的代碼沒有批評，那麼他們應該提出問題。當然，他們在這里和那裡學到了一些新東西，或者他們看到了一些出乎意料的事情，與他們做的事情有所不同。提出這些問題並獲得良好的答案可以幫助他們了解特定於您公司的實踐與常規軟件工程的最佳實踐。

如果任何人表示不願意或不願意執行審閱，特別是對您的代碼，則只提供與他們配對審閱。告訴他們您想要的東西，並請他們向您解釋代碼。如果他們的解釋遺漏了一些有趣的內容，請提出主要問題以突出您的觀點。如果他們不能完全理解，請要求他們在審查中提出一個問題，以表明您的代碼不像以前那樣具有自我說明性。然後，通過他們的一個PR或其他PR，並演示相同的原理。通過示例顯示，CR不必令人生畏，它可以為每個人提供寶貴的學習經驗。

您在評論中提到與其他同事相比，您正在做一些更複雜的事情。

這看起來像是雙重危險：您的代碼未得到審查，其他人不知道高級主題的工作原理。如果您撞上公交車，車隊就會遇到麻煩。

但這也可能是解決問題的一個角度。與您的主管討論您如何認為這會導致團隊變得脆弱，並要求選擇1-2位同事來“發起”您正在做的困難工作。這使他們成為檢查您的代碼的合理選擇，並且還改善了總線係數。

這似乎是一個過程和管理問題。首先，您在團隊中工作，所以您作為團隊成功，而您作為團隊失敗。如果無法滿足交貨要求，那就是團隊失敗。過去，如果我們在代碼審查和對等測試方面遇到問題，並且我們有一個團隊，則簽訂合同以同意在開始新的開發任務之前必須進行所有審查和對等測試，並且發現任何違反規則的人都被稱為出來。其他時候，我們只是以循環方式分配這些任務。您，您的團隊和經理需要共同解決此問題，但不要害怕提出問題，尤其是在無法滿足交貨要求的情況下。坦率，直率，但要有禮貌。另外，不要害怕問人們問題所在。您會驚訝的是，大多數時候他們實際上只是在告訴您。

可能不是您，過程或忙碌。可能僅僅是許多程序員不喜歡進行檢查。有些人不相信他們，有些人不想花時間，有些人知道他們並不那麼擅長。

像您（和我）這樣的人非常願意花大量時間來正確檢查更改。我們這樣做是有原因的。我無法說出您的原因，但是我的原因包括：
我檢查過的東西比我曾經合作過的大多數設計師都要好，
我的拼寫和閱讀比大多數人都好，所以即使您的評論也可以得到糾正，
我對其他人在系統中進行可能會影響我甚至使我們的客戶更糟的不良更改持防禦性態度，
我的早期歷史包括組織和主持老式的坐式團體檢查，這使我對我們的代碼，因此我認識到看到其他人的代碼的價值。

學習，保護，協作。參與活動的有用價值。

您可能知道其他最好的檢查員是誰。他們可能至少會分享您對檢查的興趣。看看您是否能弄清楚他們為什麼這樣做或為什麼他們擅長於此，並吸引這些本能。 “我已經對這段棘手的代碼進行了一些更改，我需要一個好人來對其進行檢查。”或者，如果他們只是團隊成員，“我需要在[特定時間範圍內]進行檢查。您能幫幫我嗎？“

我完全同意關於不願審查復雜內容以及缺乏指派人員負責的說法-我在您的問題中沒有發現任何東西表明您和您的代碼對於您的團隊是不受歡迎的！我寧願認為您的團隊在處理評論方面沒有明確的流程。

我們在團隊中談論過很多 。也許我們的一些結論可能對您和您的團隊有所幫助：

• 我們希望從審核中獲得什麼？我們不是（至少主要是在尋找這些小細節）。我們想抓住陷阱，選擇糟糕的架構等。我們還希望交流可能會發現的好的想法和改進，但這是次要的。
• 因為這是我們想要的，所以在沒有作者的情況下進行審閱將花費很長時間。這就好比不得不考慮所有作者的所有想法，但是卻沒有在開發過程中獲得經驗的好處！
• 即使提交非常簡單，也不必將其散佈在很多文件上，這樣才可以弄清楚從哪裡開始和從哪裡結束-尤其是這不是“通常的情況”代碼區域”
• 我們是經驗豐富的開發人員，老實說，我們通常對什麼是危險區域以及在我們所做的工作中可能瑣碎的事情有很好的感覺。
• 評論是分享知識的絕好機會！
• 我們的解決方案：作者必須請一個或多個隊友來進行評論。視範圍而定，它可以在辦公桌上或開會中。作者必須陳述他們所做的事情，做出的選擇和妥協以及做出的原因，然後由隊友提供反饋。這樣，責任就落在了作者身上，審閱者不必自己了解所有內容：他們讓概述的人來介紹它，並且可以回答沿途可能出現的任何問題。

我將補充一點，就個人而言，我們是一個運作良好的團隊，具有高度信任。我們不會親自收集反饋，而是以積極，令人信服的方式呈現反饋。此外，如果我們從事複雜的工作，那麼我們會保持冷靜並進行討論。這樣，即使在您必須審查實際代碼之前，我們也可以對其他人的工作進行概念性概述。

即使您的團隊未提出共享的審查策略，您也可以提出想法由此，如果您認為他們會為您工作：在開發過程中保持穩定，請隊友在您出席的地方進行評估-並確保您將在此過程中遇到的疑問和妥協告訴他們。如果您的表現很好，他們實際上可能會對您有些嚇人，因此，如果您也對它們表示懷疑，則可能會對評論放心。

• 在例行團隊會議上提出來（例如，如果您有日常站立或類似的場合）：
  • ”“我正在執行的任何任務都是代碼完成，我需要得到已審核。”
• 那一刻，找人去做：
  • “誰來照顧它/誰有時間/我可以分配誰？
• 獲得口頭承諾，如果可能的話（時間表）（午餐前，凌晨3點，當天晚些時候，明天，……）
  • “謝謝，我將其合併，這樣我們就可以滿足這樣的截止日期”
• 在您正在使用的任何系統中（例如在bitbucket，
• 如果未審查您的代碼，請在站立時再次提出來。
  • “伙計，這阻止了我，否則需要進行審查功能A下周無法發貨”

稍後，在復古（如果有的話）中進行討論，或召開臨時會議進行解釋代碼審查是每個人工作的一部分，這是一個很好的知道其他人正在做什麼的方法，了解他們如何工作以及對團隊來說是必要的以及交付任何東西，依此類推-我假設您知道哪些代碼審查對：）

我都曾經遇到過這個問題-根本原因是

• 中的一個或兩個，您產生了大量可以說是好的代碼（這意味著它們沒有實際輸入）
• 您的代碼樣式或源語言非常陌生（這意味著他們對自己的評論不抱有信心，更糟糕的是需要閱讀大量的文檔來理解它）

即使出於法律原因要求審核者而不是某些部門的異想天開，也不必直接擔心他們的審核，而是提供工具幫助他們查看您的代碼-這將使他們對代碼的整體可靠性充滿信心，而不是梳理每一行以查看是否存在錯誤

• 為您的代碼編寫測試代碼並要求對測試進行審查..嘗試圍繞測試的目的寫一個很好的描述
• 詢問並與您的老闆（？）一起創建工作項測試特定功能
• （如果可能），請收集覆蓋範圍以證明測試確實覆蓋了您期望的所有分支

這將使您的同事更輕鬆地查看您的內容已經寫完了，因為對測試做出了貢獻並看到了不錯的結果，所以他們將對它的工作充滿信心！

另外，請嘗試定期開會，讓所有成員在過去一周內展示他們認為很整潔的東西（？）。走到最後，確保不要花費大量時間-還會有更多，它們應該是很有趣的，而不是炫耀或“教導”您的事情的時間。這將有助於使每個人熟悉彼此的樣式和工具，這些樣式和工具可用於理解和發展他們的邏輯。