代碼評審每個人都要參加嘛？通過代碼評審，團隊中的每個人都有機會相互理解的代碼內容，有助于促進跨庫和整個團隊的知識共享，讓任何團隊成員都可以接手并繼續推動整個項目的演進。如何解決代碼和文檔不一致的問題？

代碼評審每個人都要參加嘛？

通過代碼評審，團隊中的每個人都有機會相互理解的代碼內容，有助于促進跨庫和整個團隊的知識共享，讓任何團隊成員都可以接手并繼續推動整個項目的演進。

如何解決代碼和文檔不一致的問題？

這里的文檔不是指Javadoc、Doxygen等生成的API文檔。對于一個負責任的團隊來說，這類文檔的更新可以保證代碼同時更新。

首先看文件是干什么用的。重要性高，必須改變:如日本外包軟件。這是以后保養的重要參考。一般的代碼不一致是由于開發人員沒有嚴格按照文檔進行編碼。或者有了新的需求變更，代碼先行，沒有回頭修改階段。應該記錄在案。

這是一種不合理的操作模式。

如何避免？

專門指派的維護人員，通常是設計師、高級工程師、PM，在變更發生時及時做出修正。另外，加大評價力度。設計評審，代碼評審。防止偏差

如何解決已經發生的偏差？

什么？;什么是錯的？;的錯誤，并糾正和警告造成偏差的人，這是沒有辦法的。

Code Review常見的5個錯誤模式？

在代碼評審時，每個人都會關心最佳實踐，但最差的實踐有時可能更有啟發性。

代碼審查對于研發是必不可少的。ampd團隊，但它并不總是正確的。本文指出了所有開發人員在提交代碼審查或拉取請求時可能會遇到的一些常見錯誤模式，并總結了這些錯誤模式:

錯誤模式:查找故障

想象一下下面的場景。代碼編寫者花費數小時甚至數天來創造他們認為最有效的解決方案。他們考慮了各種設計方案，并選擇了看起來最相關的方案。他們考慮了現有應用程序的架構，并在適當的地方進行了修改。然后，他們以拉請求的形式提交了他們的解決方案，或者開始了代碼審查的過程，他們收到的專家反饋是:

你應該使用標簽，而不是空格。我不 我不喜歡大括號在這部分的位置。文檔末尾沒有空行。你的詞庫是大寫的，所以你應該大寫句子。盡管新代碼與現有代碼的風格保持一致很重要，但這些事情幾乎不需要審計人員來完成。好的。人工審核員的成本很高，他們可以做計算機能做的事情。;t .檢查是否符合風格標準是計算機很容易完成的事情，分散了代碼審查的真正目的。

如果開發人員在代碼評審過程中看到很多這樣的注釋，說明團隊要么沒有風格指南，要么有風格指南，但是風格檢查還沒有自動化。解決方案是使用checkstyle之類的工具來確保遵循了樣式指南，或者使用sonarqube識別常見的質量和安全問題。持續集成環境可以做到這一點，而不是依賴人類審計員來警告這樣的問題。

有時候，如果沒有代碼指南，或者內部代碼風格隨時間變化，不同的部分有不同的風格，那么這個自動檢查可能會比較困難。在這種情況下，有一些方法可以應用自動檢查。例如，一個團隊可能同意提交一份報告，應用商定的代碼風格，不包含其他更改。或者一個團隊可以約定，當一個文件由于bug或者函數而被更改時，該文件也將被更新為新的樣式，并且自動化工具可以被配置為只檢查被更改的文件。

如果一個團隊有多種代碼風格，并且它可以 不要自動檢查款式，很容易落入下一個陷阱。

錯誤模式:反饋不一致

每一個被邀請評審代碼的開發人員都應該邀請至少一個或更多的意見。每個人都可以同時持有不止一種觀點。有時，代碼審查可能會陷入審查者之間關于不同方法的爭論中，例如使用streams或classic for。循環是最好的。如果團隊成員對同一段代碼有不同意見，開發人員該如何修改，結束評審，將代碼推向生產？

甚至一個評論家 的想法很容易改變，無論是在一次審查中，還是在一系列審查中。在一次審查中，審查者可能會敦促作者使用O(1)讀取操作的數據結構，在下一次審查中，審查者可能會問為什么不同。用戶會有幾種數據結構，建議用單一結構的線性搜索來簡化代碼。

當一個團隊沒有。;不清楚它的最佳實踐是什么樣的，當團隊沒有 如果不知道它的優先級是什么，就會出現這種情況:

代碼應該向更現代的Java風格發展嗎？或者更重要的是代碼一致性，所以繼續到處使用經典構造？讀取系統所有部分的O(1)數據結構很重要嗎？還是O(n)的某些部分可以接受？幾乎處處所有的設計問題都可以根據情況來回答。為了更好地了解答案，開發人員需要了解他們的應用程序和團隊的優先級。

錯誤模式:最后一分鐘設計變更

開發人員在代碼評審過程中最令人泄氣的反饋是，當評審人員從根本上不同意方案的設計或架構，強行完全重寫代碼時，他們要么通過一系列評審一步步完成(見下一節)，要么粗暴地拒絕代碼，讓作者重新打開。開始吧。

代碼審查不是審查設計的合適時機。如果團隊遵循經典的網關代碼審查，那么在最后一步將代碼展示給另一個開發人員之前，代碼應該工作，并且所有的測試都應該通過。此時此刻，事實上，幾個小時，幾天，甚至幾周(雖然我真的希望它 不是幾周；代碼評審應該是小菜一碟，但這是另一個話題)努力都花在評審的代碼上了。代碼評審中指出底層設計是錯誤的。這是對每個人的浪費。;是時候了。

代碼評審可以作為設計評審，但是如果這是代碼評審的意圖，那么評審就應該在實現之初進行。然后，在開發人員走得太遠之前，他們可以概述他們的想法，也許會有一些存根類和方法，以及一些對名稱和步驟有意義的測試，也許還可以提交一些文字或圖表，這樣團隊成員就可以對要采用的方法給出反饋。

如果團隊成員在網關評審期間(即，當代碼完成并運行時)發現了真正的演示設計問題，團隊應該更新過程以更早地定位這些問題。這可能意味著進行其他類型的回顧，如前一段中建議的回顧、白板上的想法和配對。程序，或者與技術主管討論建議的解決方案。在最終的代碼評審中發現設計問題，是對開發時間的浪費，對代碼作者的打擊也很大。

錯誤模式:乒乓球評論

在理想的情況下，作者會提交代碼供評審，評審人員會提出一些明確的解決方案。作者會建議修改并重新提交代碼，代碼會在評審后被推送。但是如果這樣的事情經常發生，誰又能告訴Code Revi呢？Ew s流程有道理？

在現實生活中，經常會發生這樣的事情:

代碼審查開始。有評論者提出了幾個建議:有的小而易，有的不修邊幅，沒有明顯的解決方案，有的比較復雜。作者做了一些改動:至少是簡單的改動，或者幾處改動，為了讓審稿人滿意。作者可以向審閱者提問以澄清一些事情，或者作者可以做出評論來解釋為什么沒有做出具體的更改。評審人員回來后，他們接受一些更新，對其他修訂提出進一步的意見，找出他們不知道的地方。;不喜歡，回答問題，并與其他評論者討論或作者對他們的觀點提出了質疑。代碼編寫人員進行更多的修改，添加更多的注釋和問題，等等。審稿人檢查修改，提出更多的意見和建議，等等。重復第5步和第6步，也許是永遠重復。在這個過程中，理論上，修改和注釋應該向零遞減，直到代碼準備好。最郁悶的是每次迭代都會帶來至少和已經結束的老問題一樣多的新問題。在這種情況下，團隊進入了代碼審查的無限循環。這有許多原因:

如果評審者很挑剔，并且評審者給出的反饋不一致，就會出現這種情況。對于陷入這些習慣的評論者來說，有無限多的問題需要發現，有無限多的觀點需要提出。當沒有明確的審稿目的，或者審稿時沒有遵循的準則時，就會之所以會出現這種情況，是因為這樣一來，每一個審核者都會覺得每一個可能出現的問題都必須找出來。它發生在不清楚什么是審查者 的注釋對代碼作者的要求。是不是每一條評論都意味著必須修改？所有的問題都暗含代碼嗎？沒有自證，需要改進？還是有些評論只是為了下次教育代碼編寫人員，提問只是為了幫助評審人員理解和學習？評論應該理解為屏蔽或者不屏蔽。如果評審人員決定需要修改代碼，他們需要清楚地說明代碼作者應該做什么。姚行動了。

了解誰決定審計是否完成也很重要。這可以通過檢查任務列表上的項目來實現，或者可以由授權足夠好的個人來完成。它通常需要一個能打破僵局，解決分歧的人。這個人可能是高級開發人員、領導或架構師。老師，甚至是團隊中的代碼編寫人員，因為在團隊中，他們之間有著高度的信任。然而，在某些時候，需要有人說審查結束了或者當這些步驟完成時，審查就結束了。

錯誤模式:幽靈審查

在這里我承認我最容易犯一個異常:重影。無論我是評審人員還是代碼作者，代碼評審總會有一個點(有時是在開始！)，在審核過程中，我沒有 完全沒有反應。也許有一個重要或有趣的功能需要我檢查，所以我決定把它留到更好的時候，那時我可以真正好好看看。也可能是復習量大，想留出足夠的時間。或者我就是作者。經過20次迭代，我就可以 t面讀和回復評論，所以我決定等等。等我腦袋準備好了再回來。

聽起來熟悉嗎？

不管什么原因，有時人們不。;在審核過程中，不要做出任何回應。這可能意味著在這個人讀完代碼之前，評審就已經死了。這是浪費。即使有人投入時間來創建一個資產(新代碼)，它也沒有。;投產前沒有增加。增加價值。事實上，當它越來越落后于其他代碼庫時，它很可能已經腐爛了。

有幾個因素會導致幽靈審查。巨大的代碼審查量是一個因素，因為誰愿意去檢查幾十或幾百個修改過的文件呢？不重視代碼審查是另一個因素，因為不重視代碼審查是真正的工作或交付結果。一部分原因是困難或令人沮喪的代碼審查經歷是另一個主要因素。沒有人愿意停止編碼(開發人員通常喜歡的東西)，參與一項耗費時間、摧毀靈魂的活動。

以下是解決幽靈審查的建議:

確保代碼審查規模較小。每個團隊都必須制定自己的定義，但這需要幾個小時或幾天的審查，而不是幾周。確保代碼評審的目的是明確的，評審者應該尋找什么是清楚的。當范圍是It 當您發現代碼中可能存在的任何問題時，很難激勵自己去做一些事情。在開發過程中留出時間進行代碼審查。最后一點可能需要團隊紀律，或者團隊可能希望采用，例如，目標或用于確定開發人員的任何東西。獎勵良好代碼評審行為和鼓勵允許時間的生產力機制。

你的團隊能做什么？

對于R ampamp團隊，專注于創建一個有效的代碼評審過程。我已經在我的博客上寫了這個，但是我想在這里分享這個過程的一部分:

代碼評審需要考慮很多事情。如果開發人員擔心每一次代碼評審中的所有事情，那么任何代碼都幾乎不可能通過評審過程。實現一個適合所有人的代碼評審。過程中，最好的辦法是考慮以下問題。

團隊為什么要做評審？當有一個明確的目的，考官 的工作會更容易，代碼作者也會減少審查過程中令人不快的意外。團隊成員在尋找什么？當有目的時，開發人員可以在審查代碼時創建一組更有針對性的檢查內容。誰將參加？用什么？誰來做評審，誰來負責解決意見，誰來最終決定代碼是否合格？團隊何時進行評審，評審何時完成？審計可以在開發人員處理代碼時或者在過程結束時反復進行。沒有明確的指導，審查可能會繼續下去。走下去，如果沒有明確的指導，代碼什么時候才能最終進行。團隊在哪里進行評審？代碼審查不會。;不需要特殊的工具，所以審查可能就像作者在他的辦公桌前向他的同事展示他們的代碼一樣簡單。一旦你回答了這些問題，你的小組團隊應該能夠創建一個運行良好的代碼審查過程。記住:代碼評審的目的應該是把代碼投入生產，而不是證明開發人員有多聰明。

結論

通過建立一個清晰的代碼評審過程，可以消除或者至少減輕代碼評審的錯誤模式。許多團隊認為他們應該進行代碼審查，但是他們沒有明確的指導方針。他們為什么要進行代碼審查？Review.

不同的團隊需要不同類型的代碼評審，正如不同的應用程序有不同的業務和性能需求。第一步是找出團隊為什么需要評審代碼，然后團隊可以開始:

自動化的簡單檢查(例如，檢查代碼風格，識別常見的錯誤，以及發現安全問題)。對評審的時間、內容和評審后由誰來決定制定明確的指導方針，將代碼評審作為開發過程中的重點工作內容來抓。為什么要進行代碼評審，這將有助于團隊創建代碼評審過程的最佳實踐，從而更容易避免代碼評審的錯誤模式。