一個人的編程能力怎么去衡量？特別是在面試中，怎么避免“高分低能兒”、“專業做題家”、“面試造火箭”，我們在工作中又是需要什么樣的編程技術和能力，這個問題其實很值得深思。

在很早以前的時候，面試會問你有多少代碼量，就是寫過多少行代碼，這個標準非常的好，基本可以衡量代碼水平，但是口說無憑啊，項目經驗也是口說無憑，既然能力考不成，那就考智商吧。

1. 關于智商

一個智商高的人，編程的潛力非常的大，特別是大公司里面基本只在乎這個，說的很簡單，但是怎么去考察智商，又是一個大難題，這就像考研，高考可能除了選拔聰明的人還需要勤奮的人，但是考研基本就是要選拔出來聰明的人，那怎么辦，考數學。數學是真科學，但是對大多數工作基本沒多少用處，但是就考智商來說，還是很公平的：聰明人能學好數學，學好數學的人一定聰明。

下面來看看編程界的騷操作：谷歌發現聰明的人擅長算法，那面試就考算法啊，然后全球編程公司都效仿。但是致命一點擅長算法的人不一定聰明，聰明的人不一定喜歡搞算法，反而不聰明的人通過刷題也可以蒙混過關。可能是沒有更好的方法吧，大家都開始卷算法的時候，還的確是可以的。但是這種內卷絲毫不產生價值，因為算法工作的時候大概率不用，就是用也可以用ChatGPT瞬間生成啊，不需要自己寫的，可謂“天下苦Leeetcode久已”。

2. 關于能力

先梳理下程序員日常的工作需要那些東西，首先就是參考各種手冊，技術文檔，讀代碼了解框架，然后制定方案，進行編碼實現。這其中一方面是對于技術手冊的掌握經驗，另一方面就是代碼的架構能力。這些東西看似跟代碼可能不沾邊，但是其都是來源于代碼的，俗話說：“一切都在代碼里”。從代碼里面跳出來又跳進去，這種能力就好像你的組長在指導你的時候一樣，這種能力可以說就是代碼review。你的組長通過review你的代碼，雖然組長第一次見，但是能夠根據代碼框架快速的看到你的實現邏輯，并指出技術方向和改進方面。代碼review開始成為評估軟件工程師的更好方法，俗話說：“行家伸伸手就知有沒有”。

代碼review能力日益重要的原因：

AI生成的代碼越來越多，AI能力不夠前，還需要人工去甄別。目前的AI更像是給專業的人提供素材，由于不保真，還需要專業的人進行甄別選用。

通常高級職務進行的代碼review多，更加的強調與他人協作，進行指導和反饋。

反映受試者是否具備全面的推理、思考和溝通視角。

對代碼的理解能力要求高，畢竟大多數時候我們是在讀代碼、抄代碼、而并非原創的去寫代碼。

review的速度快，可以更快的融入現有項目，更好更快的創造生產力。

review相對于做題，更加的貼近于實戰，直接面對團隊遇到的實際挑戰。

代碼review的一些測試項：

閱讀數據訪問、異常處理、輸入處理等一些典型的代碼，看是否能看懂，理解用法

有bug的代碼，是否能找出并解決

代碼一些代碼進行重構，策略和方法及效果

找一段運行緩慢的代碼，對性能進行優化

給一段代碼的單元測試代碼，看是否涵蓋所有情況，如何對單元測試做改進

3. 關于changelist

參考：https://google.github.io/eng-practices/review/developer/

我們在提交代碼的時候都有commit message，這里用CL代表changelist，就是描述是關于正在進行哪些更改以及為何進行更改的公共記錄。它將成為我們版本控制歷史中永久的一部分，并且多年來可能會被除您的審閱者之外的數百人閱讀。一個模板如下：

rpc: remove size limit on RPC server message freelist.

Servers like FizzBuzz have very large messages and would benefit from reuse. Make the freelist larger, and add a goroutine that frees the freelist entries slowly over time, so that idle servers eventually release all freelist entries.

標題行：使用祈使句總結，第一個單詞首字母大寫，行末不加標點

請記住標題行(title)和正文行(body)之間要有個空行

正文行：解釋做了什么(what)和為什么這么做(why)，而不是詳細描述如何做的

3.1 關于CL內容編寫

CL 描述的第一行應該是CL 正在執行的具體操作的簡短摘要，后跟一個空行。這是版本控制歷史摘要中出現的內容，因此它應該提供足夠的信息，以便將來的代碼搜索者不必閱讀您的 CL 或其整個描述來了解您的 CL 實際做了什么或它與其他 CL 有何不同。也就是說，第一行應該是獨立的，以便讀者可以更快地瀏覽代碼歷史記錄。

盡量保持你的第一句話簡短、重點突出、切中要點。對讀者來說，清晰度和實用性應該是最重要的。

按照傳統，CL 描述的第一行是一個完整的句子，寫起來就好像它是一個命令（祈使句）。例如，說“刪除FizzBuzz RPC 并將其替換為新系統。”而不是“刪除FizzBuzz RPC 并用新系統替換它。”不過，您不必將描述的其余部分寫成祈使句。

第一行應該是簡短、重點突出的摘要，而描述的其余部分應填寫詳細信息，并包括讀者全面理解變更列表所需的任何補充信息。它可能包括對正在解決的問題的簡要描述，以及為什么這是最好的方法。如果該方法有任何缺點，應該指出。如果相關，請包括背景信息，例如錯誤編號、基準測試結果和設計文檔的鏈接。

3.2 關于CL的大小

這里的大小就是一次上庫修改的功能的多少，盡可能的一次上庫，也就是一個CL只描述一個最小的功能。對于大的CL包括幾項，最好可以做拆分上庫。小CL的好處：

審稿比較快。對于審閱者來說，花 5 分鐘時間多次審閱小型 CL 比留出 30 分鐘時間審閱一個大型 CL 更容易。

審查得更徹底。隨著巨大的變化，審稿人和作者往往會因為大量的詳細評論來回變化而感到沮喪——有時甚至會遺漏或丟棄重要的觀點。

引入錯誤的可能性較小。由于您所做的更改較少，因此您和您的審閱者可以更輕松地有效地推斷 CL 的影響并查看是否引入了錯誤。

如果被拒絕，就會減少浪費的工作。如果你寫了一個巨大的 CL，然后你的審稿人說總體方向是錯誤的，那么你就浪費了很多工作。

更容易合并。處理大型 CL 需要很長時間，因此合并時會出現很多沖突，并且必須頻繁合并。

更容易做好設計。完善小變更的設計和代碼運行狀況比完善大變更的所有細節要容易得多。

減少對評論的阻礙。發送整體更改的獨立部分允許您在等待當前 CL 審核時繼續編碼。

回滾更簡單。大型 CL 更有可能會涉及在初始 CL 提交和回滾 CL 之間更新的文件，從而使回滾變得復雜（中間 CL 可能也需要回滾）。

3.3 處理審稿人的意見

審查的目標是維持我們的代碼庫和產品的質量。當審閱者對您的代碼提出批評時，請將其視為他們試圖幫助您、代碼庫和公司，而不是對您或您的能力的人身攻擊。

[禮貌和尊重]始終應放在首位。如果您不同意審閱者的觀點，請找到合作的方法：要求澄清，討論優點/缺點，并解釋為什么您的做事方法對代碼庫、用戶和/或 公司 更好。

如果您無法親自或通過視頻通話與他們交談，請向他們發送私人電子郵件。以友善的方式向他們解釋你不喜歡什么以及你希望他們采取不同的做法。

通過給代碼添加注釋來讓審稿人明白代碼的含義。

解決沖突的第一步應該始終是嘗試與審稿人達成共識。如果您無法達成共識，請參閱公司的代碼規范。

4. 關于代碼審查

參考：https://google.github.io/eng-practices/review/reviewer/

代碼審查應該關注如下方面：

設計：代碼設計良好并且適合您的系統嗎？

功能：代碼的行為是否符合作者的預期？代碼的行為方式對其用戶有利嗎？

復雜性：代碼可以變得更簡單嗎？其他開發人員將來遇到此代碼時是否能夠輕松理解和使用該代碼？

測試：代碼是否具有正確且設計良好的自動化測試？

命名：開發人員是否為變量、類、方法等選擇了清晰的名稱？

評論：評論是否清晰且有用？

風格：代碼是否遵循我們的風格指南？

文檔：開發者是否也更新了相關文檔？

在進行代碼審查時，您應該確保：

代碼設計得很好。

該功能對于代碼的用戶來說是有好處的。

任何 UI 更改都是合理且看起來不錯的。

任何并行編程都是安全完成的。

該代碼并不比需要的更復雜。

開發人員沒有實現他們將來可能需要但不知道他們現在需要的東西。

代碼有適當的單元測試。

測試是精心設計的。

開發人員為所有內容都使用了清晰的名稱。

注釋清晰且有用，并且主要解釋為什么而不是什么。

代碼有適當的文檔記錄（通常在 g3doc 中）。

該代碼符合我們的風格指南。

確保檢查您被要求檢查的每一行代碼，查看上下文，確保您正在改善代碼健康狀況，并贊揚開發人員所做的好事。

如何寫代碼評審意見：

確保您始終對代碼進行評論，而不是對開發人員進行評論，保持禮貌和尊重。

壞：“當并發顯然沒有任何好處時，為什么要在這里使用線程？”

好：“這里的并發模型增加了系統的復雜性，但我認為沒有任何實際的性能優勢。由于沒有性能優勢，因此該代碼最好是單線程而不是使用多線程。”

和善的對代碼進行評論

解釋你的推理。

在給出明確指示與僅指出問題并讓開發人員決定之間取得平衡。

鼓勵開發人員簡化代碼或添加代碼注釋，而不是僅僅向您解釋復雜性。

后記：

本文并沒有從細節代碼上說怎么去review，這還是靠各位在工程實踐中進行。但是文中描寫的一些大原則，或許能讓你在跟別人討論的過程中用上一兩句，那么就顯的逼格層次更加的高級，文中基本參考的谷歌的文檔做法。怎么裝逼？答案就是看谷歌程序員怎么做。