編程雜談-代碼review

一個(gè)人的編程能力怎么去衡量？特別是在面試中，怎么避免“高分低能兒”、“專業(yè)做題家”、“面試造火箭”，我們?cè)诠ぷ髦杏质切枰裁礃拥木幊碳夹g(shù)和能力，這個(gè)問(wèn)題其實(shí)很值得深思。

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

1. 關(guān)于智商

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

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

2. 關(guān)于能力

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. 關(guān)于changelist

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

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

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é)，第一個(gè)單詞首字母大寫，行末不加標(biāo)點(diǎn)

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

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

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

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

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

按照傳統(tǒng)，CL 描述的第一行是一個(gè)完整的句子，寫起來(lái)就好像它是一個(gè)命令（祈使句）。例如，說(shuō)“刪除FizzBuzz RPC 并將其替換為新系統(tǒng)?！倍皇恰皠h除FizzBuzz RPC 并用新系統(tǒng)替換它?！辈贿^(guò)，您不必將描述的其余部分寫成祈使句。

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

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

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

審稿比較快。對(duì)于審閱者來(lái)說(shuō)，花 5 分鐘時(shí)間多次審閱小型 CL 比留出 30 分鐘時(shí)間審閱一個(gè)大型 CL 更容易。

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

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

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

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

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

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

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

3.3 處理審稿人的意見(jiàn)

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

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

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

通過(guò)給代碼添加注釋來(lái)讓審稿人明白代碼的含義。

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

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

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

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

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

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

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

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

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

評(píng)論：評(píng)論是否清晰且有用？

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

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

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

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

該功能對(duì)于代碼的用戶來(lái)說(shuō)是有好處的。

任何 UI 更改都是合理且看起來(lái)不錯(cuò)的。

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

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

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

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

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

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

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

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

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

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

如何寫代碼評(píng)審意見(jiàn)：

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

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

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

和善的對(duì)代碼進(jìn)行評(píng)論

解釋你的推理。

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

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

后記：

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