做了1000次Code Review，我學(xué)到這3點(diǎn)經(jīng)驗(yàn)

作者：Steven Heidel 2020-02-07 11:50:24

Code Review 是保證代碼質(zhì)量的重要手段。Steven Heidel 曾在 LinkedIn 負(fù)責(zé) Code Review，他在本文總結(jié)了常見的代碼問題并提出修改方案。

當(dāng)我在 LinkedIn 工作時(shí)，工作的很大一部分內(nèi)容是做 Code Review。在這個(gè)過程中，我發(fā)現(xiàn)一些人很容易犯的錯(cuò)誤，于是把錯(cuò)誤整理起來并分享給團(tuán)隊(duì)。

經(jīng)驗(yàn) 1：當(dāng)出現(xiàn)錯(cuò)誤時(shí) Throw an exception

我看到的一個(gè)常見模式是：

List<String> getSearchResults(...) { 
  try { 
    List<String> results = // make REST call to search service 
    return results; 
  } catch (RemoteInvocationException e) { 
    return Collections.emptyList(); 
  } 
}

上面的方法可能是很多新手工程師的做法，但這種模式會(huì)有問題。在我曾經(jīng)參與的移動(dòng)應(yīng)用中，這種模式導(dǎo)致移動(dòng)應(yīng)用程序的故障。用戶搜索開始后，我們的后端發(fā)生錯(cuò)誤開始 throwing exceptions，但在應(yīng)用程序的 API server 中并沒有 throwing exceptions。

因此，從應(yīng)用角度看，前端會(huì)收到 200 個(gè)成功的響應(yīng)，然后顯示空白的搜索結(jié)果給使用者，而團(tuán)隊(duì)卻毫不知情。

如果 API thrown an exception，那我們的監(jiān)控系統(tǒng)會(huì)立刻發(fā)現(xiàn)它，并能及時(shí)修復(fù)。

很多時(shí)候，當(dāng)捕捉到異常后，我們傾向于返回 empty object。Java 中 empty object 的樣例包括 Optional.empty()、null 和 empty list。這種情況經(jīng)常發(fā)生在 URL 解析中。如果 URL 無法從字符串解析得到的話，不要返回 null，而要問問自己：

URL 格式為什么是不合法的？這是一個(gè)需要在 upstream 解決的數(shù)據(jù)問題嗎？

對于這種任務(wù)來說，empty object 并不是恰當(dāng)?shù)墓ぞ摺Ｈ绻霈F(xiàn)異常行為，那么就應(yīng)該 throw an exception。

經(jīng)驗(yàn) 2：盡可能使用最具體的類型（type)

基本而言，這條建議恰好與 stringly typed programming 相反。

我經(jīng)常看到下面所示的代碼：

void doOperation(String opType, Data data);  
// where opType is "insert", "append", or "delete", this should have clearly been an enum 
 
String fetchWebsite(String url); 
// where url is "https://google.com", this should have been an URN 
 
String parseId(Input input); 
// the return type is String but ids are actually Longs like "6345789"

用最具體的類型 (type）可以避免很多 bug。

現(xiàn)在問題是：好心的程序員為什么會(huì)寫出糟糕的 stringly typed 代碼？

答案在于外部世界不是強(qiáng)類型的。字符串有很多不同的來源，比如：

url 中的查詢和路徑參數(shù)
JSON
不支持枚舉的數(shù)據(jù)庫
編寫糟糕的庫

在上述場景中，我們應(yīng)使用如下的策略來避免該問題：將字符串解析和序列化放在程序的邊緣之處。

下面是這樣一個(gè)樣例：

// Step 1: Take a query param representing a company name / member id pair and parse it 
// example: context=Pair(linkedin,456) 
Pair<String, Long> companyMember = parseQueryParam("context"); 
// this should throw an exception if malformed 
 
// Step 2: Do all the stuff in your application 
// MOST if not all of your code should live in this area 
 
// Step 3: Convert the parameter back into a String at the very end if necessary 
String redirectLink = serializeQueryParam("context");

這種方式有很多優(yōu)點(diǎn)。立即發(fā)現(xiàn)格式錯(cuò)誤的數(shù)據(jù)；如果出現(xiàn)任何問題，應(yīng)用程序?qū)⑻崆?fails。數(shù)據(jù)被驗(yàn)證一次后，不必在整個(gè)應(yīng)用程序中繼續(xù)捕獲解析異常。

此外，強(qiáng)類型使方法簽名更具描述性，我們不再需要在每個(gè)方法上編寫那么多的 javadocs。

經(jīng)驗(yàn) 3：用 Optionals 而非 nulls

Java 8 帶來最棒的特性之一是Optional類，它代表一個(gè)可能存在也可能不存在的實(shí)體。

一個(gè)小問題：

唯一擁有自己縮寫的例外（exception）是什么？答案是 NPE 或空指針異常。截至目前，它是 Java 中最常見的異常，并被稱為價(jià)值 10 億美元的錯(cuò)誤 (https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare )。

Optional能讓我們完全從程序中移除 NPE。但是，必須以正確的方式使用它。如下是關(guān)于使用Optional的一些建議：

我們不能在得到Optional的任何時(shí)候都簡單地調(diào)用它的.get()，相反，我們要仔細(xì)考慮Optional不存在的情況并給出一個(gè)合理的默認(rèn)值；
如果還沒有合理的默認(rèn)值，那么像.map()和.flatmap()這樣的方法允許我們推遲到以后再做決定；
如果外部庫返回null來表示為空的情況，那么立即使用Optional.ofNullable()wrap 該值。相信我，你以后會(huì)感謝自己的。null 值在程序內(nèi)部有“bubble up”的傾向，所以最好在源代碼中停止它們；
在方法的返回類型中使用Optional。這種做法非常好，因?yàn)槲覀儾恍枰x取 javadoc 來確定值是否可能不存在。

額外建議：盡可能采用“Unlift”方法

我們應(yīng)避免下面所示的方法：

// AVOID: 
CompletableFuture<T> method(CompletableFuture<S> param); 
// PREFER:  
T method(S param); 
 
// AVOID: 
List<T> method(List<S> param); 
// PREFER: 
T method(S param); 
 
// AVOID:  
T method(A param1, B param2, Optional<C> param3); 
// PREFER: 
T method(A param1, B param2, C param3); 
T method(A param1, B param2); 
// This method is clearly doing two things, it should be two methods 
// The same is true for boolean parameters