谷歌首頁代碼?代碼評審的主要目的是确保代碼庫的整體質量随時間推移逐步得到提升這是一項艱巨的任務，因為代碼庫整體質量常常會随着每次提交代碼質量的小幅下降而退化代碼評審就是确保每個 CL（變更列表）的質量，保證代碼庫整體質量不會随着時間的推移而下降，接下來我們就來聊聊關于谷歌首頁代碼?以下内容大家不妨參考一二希望能幫到您!

谷歌首頁代碼

代碼評審的主要目的是确保代碼庫的整體質量随時間推移逐步得到提升。這是一項艱巨的任務，因為代碼庫整體質量常常會随着每次提交代碼質量的小幅下降而退化。代碼評審就是确保每個 CL（變更列表）的質量，保證代碼庫整體質量不會随着時間的推移而下降。

每個企業甚至每個團隊都有自己的code review方式，無所謂好壞，都可以互相借鑒，取長補短。谷歌的code review經驗實踐一直是業界比較認可的方式，來看看谷歌怎麼做的吧。

一般來說，如果 CL 達到可以提升系統整體代碼質量的程度，就可以讓它們通過了，即使它們可能還不完美。這是所有代碼評審準則的最高原則。

當然，也有例外的時候。例如，如果 CL 中包含了系統不需要的功能，那麼即使代碼寫得很好，評審人員也可以拒絕讓它們通過。

因為這個世界上沒有“完美”的代碼，隻有更好的代碼。評審人員不應該要求開發人員對 CL 中的每一個微小部分都進行細緻入微的打磨，而應該在滿足需求和變更重要性之間做出權衡。評審人員不應該過度追求完美，而應追求持續改進。如果一個 CL 能夠從整體上提高系統的可維護性、可讀性和可理解性，那它就不應該僅僅因為它不夠“完美”而被延遲幾天甚至幾周。

以上是代碼評審的大指導方向。

我們再來看看具體的細分原則：

1.客觀的技術和數據比個人意見和偏好更重要

2.在代碼風格方面，可以參考（谷歌風格指南）。任何沒有在這個風格指南中出現的東西（比如空格等）都屬于個人偏好。

3.如果沒有其他适用的原則，評審人員可以要求開發人員與當前代碼庫保持一緻，隻要不破壞系統的整體代碼質量。

代碼評審究竟要關注哪些方面？

功能

這個 CL 是否有意義？對戶來說有好處嗎？

設計

代碼評審中最重要的部分是 CL 的總體設計。

我們要考慮 CL 中不同代碼段之間的交互是有意義的嗎？

這個變更應該屬于代碼庫，還是屬于某個包？

它與系統的其他部分可以良好地集成嗎？

現在是引入這個變更的好時機嗎？

評審人員要警惕過度設計，鼓勵開發人員隻解決現在需要解決的問題，而不是将來可能需要解決的問題。

未來的問題應該在它們出現之後再去解決，因為到了那個時候我們可以看到它們的實際狀況和需求。

過度設計是一種特殊的複雜性，開發人員把代碼寫得比實際需要的更通用，或者增加了系統當前不需要的功能。

複雜性

CL 比實際需要的更複雜嗎？

從每一層面檢查 CL，細到每一行代碼，它們是不是太複雜了？“太複雜”通常意味着“閱讀代碼的人難以很快理解它們”，也意味着“開發人員在調用或修改這些代碼時可能會引入 bug”。

測試

要求開發人員進行單元測試、集成測試或端到端測試。

一般來說，CL 中應該包含測試，除非這個 CL 隻是為了處理緊急情況。

請記住，測試代碼也是需要維護的。

命名

開發人員是否使用了良好的命名方式？

注釋

開發人員有沒有用自然語言寫出清晰的注釋？

他們所寫的注釋都是必需的嗎？

代碼風格

要确保 CL 遵循了适當的指南。

請不要隻是基于個人偏好來阻止 CL 的提交。

開發人員不應該将風格變更與其他變更放在一起，這樣很難看出 CL 發生了哪些變化，導緻合并和回滾變得更加複雜。

如果開發人員想要重新格式化整個文件，讓他們将重新格式化後的文件作為單獨的 CL，并将功能變更作為另一個 CL。

文檔

如果 CL 導緻用戶構建、測試、交互或發布代碼的方式發生了變化，請确保相關的文檔也得到了更新，包括 README、g3doc 頁和其他生成的參考文檔。

如果 CL 有移除或棄用代碼，請考慮一下是否也應該删除相關的文檔。

查看每一行代碼

查看每一行代碼，不要隻是粗略地掃一下類、函數或代碼塊，并假定它們都能正常運行，至少應該要理解這些代碼都在做些什麼。

如果代碼很複雜或者你難以快速看懂它們，導緻評審速度變慢，要讓開發人員知道，并在進行進一步評審之前讓他們做一些澄清。如果你看不懂這些代碼，其他開發人員很可能也看不懂。因此，要求開發人員澄清代碼其實也是在幫助未來的開發人員更好地理解代碼。

如果你理解代碼，但又覺得沒有資格做代碼評審，可以确保有資格的 CL 評審人員在代碼評審時考慮到了安全性、并發性、可訪問性、國際化等問題。

上下文

代碼評審工具通常隻顯示被修改的代碼，但有時候你需要查看整個文件，确保代碼變更是有意義的。

例如，你可能隻看到新添加了四行代碼，但如果你看一下整個文件，會發現這四行代碼位于一個 50 多行的方法中，這個時候需要将這個方法拆分為更小的方法。

好的一面

代碼評審通常隻關注錯誤的東西，但其實也應該鼓勵和贊賞好的代碼實踐。

如果你在 CL 中看到一些不錯的東西，要讓開發人員知道，特别是當他們以一種很好的方式解決了問題。

有時候，讓開發人員知道他們做對了事情比讓他們知道做錯了事情更有價值。

因此總結下來，在進行代碼評審時，你要确保：

1. 良好的代碼設計
2. 功能對用戶來說是有用的
3. UI 變更應該是合理的
4. 并行編程是安全的
5. 代碼複雜性不要超過應有的程度
6. 不需要實現可能會在未來出現的需求
7. 有适當的單元測試
8. 精心設計的測試用例
9. 使用了清晰的命名方式
10. 清晰而有用的代碼注釋
11. 恰如其分的代碼文檔化
12. 代碼要遵循風格指南，而不是個人喜好
13. 查看上下文，檢查每一行代碼
14. 為表現不錯的開發人員點贊

評審流程

知道了代碼評審過程中要關注哪些點之後，是時候了解下代碼評審流程了。

第一步：從整體查看代碼變更

先看一下 CL 描述，看看這個 CL 做了些什麼。做出這個變更有意義嗎？如果這個變更是不必要的，請立即做出回複，并解釋為什麼不應該發生這個變更。在你拒絕這樣的變更時，可以向開發人員建議他們應該做些什麼。

第二步：檢查 CL 的主要部分

找到 CL 的主要文件。通常一個 CL 會有一個包含了主要邏輯變更的文件，也就是 CL 的主要部分。先看看這些主要部分，有助于了解整個上下文，加快代碼評審速度。如果 CL 太大，以緻于你無法确定哪些部分是主要的，可以詢問開發人員，或者讓他們把 CL 拆分成多個 CL。

如果 CL 的主要部分存在嚴重的設計問題，要立即回複開發人員，即使你還沒有時間檢查 CL 的其餘部分。這個時候檢查 CL 的其餘部分可能是在浪費時間，因為如果主要部分存在嚴重的設計問題，那麼其他部分就變得無關緊要了。

第三步：按照适當的順序檢查 CL 的其餘部分

在确認整體 CL 沒有嚴重的設計問題之後，試着按照某種邏輯順序來檢查其他文件，确保不會錯過任何一個需要檢查的文件。通常，在你檢查完主要文件之後，按照代碼評審工具顯示它們的順序來浏覽每個文件就可以了。你也可以在檢查主要代碼之前先查看測試代碼，這樣可以對代碼變更有一個大緻的概念。

代碼評審回推

有時候，開發人員會回推代碼評審。他們可能不同意你的意見，或者他們抱怨你太嚴格了。

誰是對的？

如果開發人員不同意你的意見，先花點時間想一下他們是不是對的。通常，他們比你更熟悉代碼，所以可能對代碼的某些方面更了解。他們的論點有道理嗎？從代碼質量角度來看，他們的回推是有道理的嗎？如果是，就讓他們知道他們是對的，這個問題就解決了。

然而，開發人員并不總是正确的。在這種情況下，評審人員要進一步解釋為什麼他們的建議是正确的。

如果評審人員認為他們的建議可以改善代碼質量，并認為評審所帶來的代碼質量改進值得開發人員做出額外的工作，那麼他們就應該堅持。改善代碼質量往往是由一系列的小步驟組成的。

有時候你需要花很多時間反複解釋，但要始終保持禮貌，并讓開發人員知道你知道他們在說什麼。

激動的開發人員

有時候，評審人員會認為如果他們堅持要開發人員做出改動，會讓開發人員感到不安。開發人員有時候确實會感到沮喪，但這種感覺通常都很短暫，之後他們會非常感謝你幫助他們提高了代碼質量。如果你在評審過程中表現得很有禮貌，開發人員一點都不會感到不安，這種擔心可能是多餘的。通常，令開發人員感到不安的是你寫注解的方式，而不是你對代碼質量的堅持。

稍後再解決

一種常見的回推原因是開發人員希望盡快完成任務。他們不想經過一輪又一輪的代碼評審，他們說他們會在後續的 CL 中解決遺留問題，你現在讓 CL 通過就可以了。一些開發人員會做得很好，他們在提交 CL 後立即就開發後續的 CL。但經驗表明，開發人員開發原始 CL 的時間越長，他們進行後續修複的可能性就越小。除非開發人員在提交 CL 之後立即進行修複，否則在通過之後通常不會再去做這件事情。這并不是因為開發人員不負責任，而是因為他們有很多工作要做，而修複工作通常會被遺忘。所以，最好讓開發人員馬上把 CL 修複掉。

如果 CL 引入了新的複雜性，在提交之前必須将其清理掉，除非是緊急情況。如果 CL 暴露了一些目前還無法解決的問題，開發人員需要把 bug 記錄下來，并将其分配給自己，這樣它就不會被遺漏。他們還可以在代碼中加入 TODO 注釋，指向已經記錄好的 bug。

抱怨評審太嚴格

如果你之前的代碼評審很放松，然後突然變得嚴格起來，可能會引起一些開發人員的抱怨。不過沒關系，加快代碼評審速度通常會讓這些抱怨逐漸消失。

有時候，這些抱怨可能需要幾個月的時間才能消除，但開發人員到最後通常會看到代碼評審的價值，因為他們看到了嚴格的代碼評審有助于産出優秀的代碼。有時候，抗議最大聲的人甚至會成為你最堅定的支持者。

解決沖突

如果你遵循了上述方法，但仍然會在評審過程中遇到無法解決的沖突，請再次參閱代碼評審标準，了解那些有助于解決沖突的指導原則。

代碼評審的速度

為什麼代碼評審要快速進行？

在谷歌，對開發團隊的整體交付速度（而不是針對個體開發人員寫代碼的速度）進行了優化。個體開發速度也很重要，但其重要性比不上整個團隊的開發速度。

如果代碼評審的速度很慢，就會發生以下這些事情：

• 團隊的整體開發速度降低了。如果個體開發人員無法快速地對評審做出響應，可能是因為他們有其他事情要做。但是，如果每個 CL 都要等待一次又一次的評審，那麼其他成員的新特性和 bug 修複就會被延遲，可能是幾天、幾周甚至是幾個月。
• 開發人員開始對代碼評審流程提出抗議。如果評審人員要隔幾天才回複一次，但每次都要求對 CL 進行重大修改，開發人員可能會覺得很沮喪。通常，他們會抱怨評審人員太過嚴苛。如果評審人員能夠快速提供反饋，抱怨就會消失，即使他們要求做出的修改是一樣的。代碼評審過程的大多數抱怨實際上可以通過加快評審速度來解決。
• 代碼質量受影響。如果評審速度很慢，開發人員的壓力也會随之增加，因為他們不能提交不甚完美的 CL。緩慢的評審流程還會阻礙代碼清理、重構和對現有 CL 做出進一步改進。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部