日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

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

創(chuàng)新互聯(lián)專注于蕉城企業(yè)網(wǎng)站建設(shè),響應(yīng)式網(wǎng)站,購物商城網(wǎng)站建設(shè)。蕉城網(wǎng)站建設(shè)公司,為蕉城等地區(qū)提供建站服務(wù)。全流程按需制作網(wǎng)站，專業(yè)設(shè)計，全程項目跟蹤，創(chuàng)新互聯(lián)專業(yè)和態(tài)度為您提供的服務(wù)

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

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

我看到的一個常見模式是：

 
 
 

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

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

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

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

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

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

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

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

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

我經(jīng)?？吹较旅嫠镜拇a：

 
 
 

  
  
  
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)在問題是：好心的程序員為什么會寫出糟糕的 stringly typed 代碼？

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

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

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

下面是這樣一個樣例：

 
 
 

  
  
  
// Step 1: Take a query param representing a company name / member id pair and parse it
  
  
  
// example: context=Pair(linkedin,456)
  
  
  
Pair 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)點。立即發(fā)現(xiàn)格式錯誤的數(shù)據(jù)；如果出現(xiàn)任何問題，應(yīng)用程序?qū)⑻崆?fails。數(shù)據(jù)被驗證一次后，不必在整個應(yīng)用程序中繼續(xù)捕獲解析異常。

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

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

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

一個小問題：

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

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

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

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

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

 
 
 

  
  
  
// AVOID:
  
  
  
CompletableFuture method(CompletableFuture param);

  
  
  
// PREFER: 
  
  
  
T method(S param);
  
  
  

  
  
  
// AVOID:
  
  
  
List method(List param);

  
  
  
// PREFER:
  
  
  
T method(S param);
  
  
  

  
  
  
// AVOID: 
  
  
  
T method(A param1, B param2, Optional 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
 
 
 

上述不推薦使用的方法有哪些共同點？那就是它們都使用了 container objects 作為參數(shù)，比如 Optional、List 或 Task。

如果返回類型是相同種類的 container，那就更糟糕了（比如，param methods 接收 Optional，返回值也是 Optional）。

為什么呢？

1)Promise method(Promise param)要比 2)A method(B param)更缺少靈活性。

如果有一個Promise的話，我們可以用 1)，也能通過.map函數(shù)使用 2)（即promise.map(method)）。

但是，如果只有一個 B 的話，我們很容易使用 2)，但是無法使用 1)，這樣來看，2) 是更具靈活性的方案。

我喜歡將其稱為“unlifting”，因為它與常見的函數(shù)式工具方法“l(fā)ift”恰好相反。采用這種方式重寫會讓方法更具靈活性，對調(diào)用者更加易用。