LinkedIn工程師：我從千行代碼審查里學到了什麼

當我在LinkdIn工作的時候，很大一部分工作內容都涉及代碼審查。有些審閱建議會一再出現，所以我決定匯總成表，一併分享給大家。

文/Steven Heidel

譯/ 之餚

來源/ https://hackernoon.com/what-i-learned-from-doing-1000-code-reviews-fe28d4d11c71

以下是我的3+1項常見代碼審查建議。

建議1：出現問題時拋出異常

一個常見模式是這樣的：

這個模式實際上會導致一個我維護的APP的中斷，然後我們用的搜索後端就開始拋出異常。但是，由於APP的API伺服器和異常部分有相似之處，我們得到了200個成功響應，同時為每個搜索查詢提供了空表。

如果API真的拋出異常，那我們的監控系統就會立即採取行動，馬上將其修好。

很多時候，當你發現一個異常之後，可能會試圖返回一個空對象，Java里的空對象就有Optional.empty(), null和空表。而問題常常在URL解析的時候出現。如果URL不能從字元串里解析出來，在返回空對象之前問問自己：「為什麼URL格式不正確？有沒有可能是需要在上游修復的數據問題呢？」

這時候空對象就不是一個好的解決工具了，你應該拋出異常試試。

建議2：儘可能使用最特定的類型

這個建議和字元串型編程恰恰相反。

我常常看到這樣的代碼：

儘可能地使用最特定的類型可以讓你避免一群BUG，同是也是選擇Java這類強類型語言的基本原因。

所以現在的問題是：怎麼不讓有想法的程序員繼續寫出糟糕的字元串型代碼呢?答案是：由於外部世界不是強類型的，字元串的來源數不勝數，例如：

· URL里的查詢和路徑參數

· JSON

· 不支持枚舉的資料庫

· 寫得很差的庫

在上述這些情況下，你應該使用這個策略來避免這類問題：將字元串解析和序列化放在程序的邊緣。比如：

這個方法有很多優點。你能馬上發現格式錯誤的數據；如果有任何問題，應用程序會早早地停止工作；只要數據已經被驗證過，你就不用在整個應用里捕捉解析異常。另外，強類型使得更多的描述性方法簽名成為可能，你也不用在每個方法上寫這麼多Javadoc了。

建議3：用Optional而不是null

Java 8里最好的特徵之一就是Optional類，他表示一個理論上存在或不存在的實體。

但也有些細碎問題：他的縮寫會有什麼錯誤？。答案是：空指針異常(NPE)。這是Java里迄今為止最常見的異常，被稱為十億美元的錯誤。

Optional讓你可以從程序中完全刪除NPE，但他必須得正確使用。以下是一些關於使用Optional的建議：

在你想用Optional的時候，不要就單單調用.get()，仔細考慮下如果Optional不存在的情況，然後想一個合理的默認值出來。

如果你暫時想不出來，.map()和.flatMap()還能幫你多拖點時間。

如果外部庫返回null，那就馬上用Optional.ofNullable()打包該值。相信我，以後你會感謝當時的自己的。空值在程序里會有「冒泡」的傾向，所以最好從源頭上阻止他們。

在返回類方法里使用Optional，這樣你就不用讀Javadoc就能知道值是否存在。

額外建議：儘可能用「非提升」(unlifting)方法

你應該避免這樣的方法：

所有要避免的方法有什麼共同點呢?他們都用Optional, List或者Task這樣的容器對象作為方法參數，如果返回類型也是相同容器的話就更糟糕了（即單參數方法輸入一個Optional並且返回一個Optional）。

為什麼這麼說呢？

1) Promise method(Promise param)不太靈活

2) A method(B param)

如果你有Promise ，你可以用1)例或者通過「提升」.map來用2)例(即 promise.map(method))。

但如果你只有B，你就只能用2)而不能用1)，這顯得2)使用更寬泛。

我喜歡把這個方法叫做「非提升」(unlifting)，因為他和常用的lift恰恰相反，我們能把方法改得更為靈活，方便用戶使用。

— 完 —

快點掃我~

GIF/1K

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！