編程雜談-代碼review

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

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

1. 關(guān)于智商

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

下面來看看編程界的騷操作：谷歌發(fā)現(xiàn)聰明的人擅長算法，那面試就考算法啊，然后全球編程公司都效仿。但是致命一點(diǎn)擅長算法的人不一定聰明，聰明的人不一定喜歡搞算法，反而不聰明的人通過刷題也可以蒙混過關(guān)?？赡苁菦]有更好的方法吧，大家都開始卷算法的時候，還的確是可以的。但是這種內(nèi)卷絲毫不產(chǎn)生價(jià)值，因?yàn)樗惴üぷ鞯臅r候大概率不用，就是用也可以用ChatGPT瞬間生成啊，不需要自己寫的，可謂“天下苦Leeetcode久已”。

2. 關(guān)于能力

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

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

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

通常高級職務(wù)進(jìn)行的代碼review多，更加的強(qiáng)調(diào)與他人協(xié)作，進(jìn)行指導(dǎo)和反饋。

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

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

review的速度快，可以更快的融入現(xiàn)有項(xiàng)目，更好更快的創(chuàng)造生產(chǎn)力。

review相對于做題，更加的貼近于實(shí)戰(zhàn)，直接面對團(tuán)隊(duì)遇到的實(shí)際挑戰(zhàn)。

代碼review的一些測試項(xiàng)：

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

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

代碼一些代碼進(jìn)行重構(gòu)，策略和方法及效果

找一段運(yùn)行緩慢的代碼，對性能進(jìn)行優(yōu)化

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

3. 關(guān)于changelist

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

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

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.

標(biāo)題行：使用祈使句總結(jié)，第一個單詞首字母大寫，行末不加標(biāo)點(diǎn)

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

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

3.1 關(guān)于CL內(nèi)容編寫

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

盡量保持你的第一句話簡短、重點(diǎn)突出、切中要點(diǎn)。對讀者來說，清晰度和實(shí)用性應(yīng)該是最重要的。

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

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

3.2 關(guān)于CL的大小

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

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

審查得更徹底。隨著巨大的變化，審稿人和作者往往會因?yàn)榇罅康脑敿?xì)評論來回變化而感到沮喪——有時甚至?xí)z漏或丟棄重要的觀點(diǎn)。

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

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

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

更容易做好設(shè)計(jì)。完善小變更的設(shè)計(jì)和代碼運(yùn)行狀況比完善大變更的所有細(xì)節(jié)要容易得多。

減少對評論的阻礙。發(fā)送整體更改的獨(dú)立部分允許您在等待當(dāng)前 CL 審核時繼續(xù)編碼。

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

3.3 處理審稿人的意見

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

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

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

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

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

4. 關(guān)于代碼審查

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

代碼審查應(yīng)該關(guān)注如下方面：

設(shè)計(jì)：代碼設(shè)計(jì)良好并且適合您的系統(tǒng)嗎？

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

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

測試：代碼是否具有正確且設(shè)計(jì)良好的自動化測試？

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

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

風(fēng)格：代碼是否遵循我們的風(fēng)格指南？

文檔：開發(fā)者是否也更新了相關(guān)文檔？

在進(jìn)行代碼審查時，您應(yīng)該確保：

代碼設(shè)計(jì)得很好。

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

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

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

該代碼并不比需要的更復(fù)雜。

開發(fā)人員沒有實(shí)現(xiàn)他們將來可能需要但不知道他們現(xiàn)在需要的東西。

代碼有適當(dāng)?shù)膯卧獪y試。

測試是精心設(shè)計(jì)的。

開發(fā)人員為所有內(nèi)容都使用了清晰的名稱。

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

代碼有適當(dāng)?shù)奈臋n記錄（通常在 g3doc 中）。

該代碼符合我們的風(fēng)格指南。

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

如何寫代碼評審意見：

確保您始終對代碼進(jìn)行評論，而不是對開發(fā)人員進(jìn)行評論，保持禮貌和尊重。

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

好：“這里的并發(fā)模型增加了系統(tǒng)的復(fù)雜性，但我認(rèn)為沒有任何實(shí)際的性能優(yōu)勢。由于沒有性能優(yōu)勢，因此該代碼最好是單線程而不是使用多線程?！?/p>

和善的對代碼進(jìn)行評論

解釋你的推理。

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

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

后記：

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