遵照這些原則讓你開發效率提升一倍

1、概述

在園子裏面有不少關於各類技術細節的研究文章，都是比較牛逼的框架研究；可是一直沒有看到關於怎麼樣提升開發效率的文章，大多提升開發效率的文章都是關於自動化等方面的輔助工具類型的，而不是開發中的一些小技巧；今天從編碼規範、編碼技巧、開發思想、設計模式等各方面的經驗來分享如何提升開發效率。

2、實際場景

在這個先後端分離盛行的開發年代，分工比較明確，開發者分前端開發者和後端開發者，然而感到欣慰的是.net 開發者大可能是擔任着全棧開發的職責，有經驗的開發者都是從前端走過來的，說白了前端業務代碼對後端開發者來講那都不是事。
先後端分離前：幾年前先後端還未分離的時候，各類前端框架還未流行的時候，開發者的效率算是比較低下，後端幹前端的活，甚至前端和後端夾雜工做，致使了工做開發容易亂，須要相互依賴，不能徹底並行工做，這致使了開發效率底的一個極大的緣由，同時開發出來的東西體驗也是不好。
先後端分離：職責分明，後端專一後端的開發，前端專一前端的開發；相互依賴關係很弱，後端能夠先定義開發接口，前端頁面及mock 接口對接，最後聯調測試時間先後端打經過；先後端徹底能夠並行開發，開發週期縮短一倍時間；不過這也就會致使了一個致命的問題，大多開發者只管本身的那一部分，不會以全局考慮，致使的一個問題就是聯調測試時間代價太大,遇到問題相互甩鍋。

先後端都存在的問題，會再聯調測試時間所有暴漏出來，這也是爲何聯調測試時間會花費那麼長時間，甚至晚上加班加點再處理問題的緣由，總結以下：

• 開發過程當中不夠謹慎，全是空異常問題
• 代碼不規範，代碼邏輯嵌套層次太深，牽一髮而動全身，以致於修改這裏，爆露出那邊的問題出來，不會適當的解耦
• 後端接口返回的字段含義不明確，不清晰，甚至徹底跟字段含義違背，好比數據庫中有一個int 類型的Type字段，而前端須要類型的中文名稱，後端開發者偷懶直接用Type 字段返回字段中文名稱，後面前端須要int 類型的Type 有不知道加什麼字段爲好，致使修修改改，影響效率，下面我會具體分享細節。
• 眼觀不足，不會考慮後續的需求變動擴展
• 沒有設計模式思想，致使維護成本變大
  下面從幾個方面點來具體分析

3、空異常

1.1 不可信原則

做爲開發者，你均可以把本身做爲方法調用者的第三方，不須要去關注方法的實現，只須要關注調用方法我應該獲得什麼結果；然而做爲調用者第三方，你都須要認爲實現者的方法都是不可信狀態，只須要秉承該原則，基本上你就跟空異常沒有緣分了.

1.2 ?. （null條件運算符）

先來看一下如下代碼：

[HttpGet]
   public async Task<DataResponse<bool>> GetTest()
   {
        var list = GetList();//獲取List 列表
        if (list?.Count <= 0)
        {
            return DataResponse<bool>.AsError("沒有獲取到數據");
        }
        //TODO 更新操做
        return DataResponse<bool>.AsSuccess(true);
   }

上面代碼不少人可能會這麼寫，其實是存在問題的list?.Count <=0 實際上在list 爲空的時候就成了null<=0 判斷了，則也是false，不符合預期結果，正確的代碼以下：

[HttpGet]
   public async Task<DataResponse<bool>> GetTest()
   {
        var list = GetList();//獲取List 列表
        if ((list?.Count??0) <= 0)
        {
            return DataResponse<bool>.AsError("沒有獲取到數據");
        }
        //TODO 更新操做
        return DataResponse<bool>.AsSuccess(true);
   }

這裏就引用了?? 運算符（空合併運算符）

1.3 ?? （空合併運算符）

MSDN上面的解釋：?? 運算符稱爲 null 合併運算符，用於定義能夠爲 null 值的類型和引用類型的默認值。若是左操做數不爲 null，則此返回左操做數；不然當左操做數爲 null，返回右操做數。

1.4 如何遠離空異常？

秉承原則：不可信原則，什麼是不可信原則呢？你調用方法都任務改方法是不可信的，包括本身寫的方法；這在敏捷快速開發中更明顯，特別是調用團隊中別人開發的微服務api ，你不須要關注方法的實現，只須要關注方法的結果便可，可是也不能太過於相信它；全部的返回結果你都須要判斷是不是null 的結果數據，多結合?. 和?? 運算符進行合理的邏輯處理，可讓你的項目今後遠離空異常。

2、If else 解套

先來看一看比較有趣的網絡上的圖片

2.1 取反原則

對於上面的if else 嵌套業務你們是否是常常遇到，看到這種代碼會很是的頭疼，難於維護，影響開發效率，同時也容易出現bug。
有經驗的開發者一定會對上面這段代碼進行優化，個人經驗是取反原則。
什麼是取反原則呢？把不符合的條件先 return 下去，到最後留下符合條件的邏輯，這就是取反原則，一眼看下來就只有一層嵌套，不會存在多層嵌套。
咱們來看下我遇到的實際場景代碼，源代碼大致以下：

if (condition)
{
    if (condition1)
    {
        if(condition2)
        {
            if (condition3)
            {
                if (condition4)
                {
                    // do something
                }
                else
                {
                    // do something
                }
            }
            else
            {
                // do something
            }
        }
        else
        {
            // do something
        }
    }
    else
    {
        // do something
    }
}
else
{
    // do something
}

取反原則優化後的代碼以下：

if (!condition)
  {
     // do someting
      return;
  }
  if (!condition1)
  {
     // do someting
      return;
  }
  if (!condition2)
  {
     // do someting
      return;
  }
  if(!condition3)
  {
     // do someting
      return;
  }
  if(!condition4)
  {
     // do someting
      return;
  }
  // do someting

3、必要的設計模式
開發過程當中不要一個鏈路寫到底，須要把某塊業務先想好，定位明確，該業務是應該屬於哪一塊，哪一類業務，後續可能會出現哪些方面的業務變更，適當的引入設計模式，那麼多的設計模式，總有一個適合你當時開發的場景；
設計模式的選取須要對該模塊的做用及定義清晰，多思考，多歸類，天然而然心中就有了合適的設計模式的考量。

4、必要的單元測試
作到每一個方法單元測試，最好是全路徑覆蓋到每一條分支的單元測試，先從小的方法單元測試，底層的方法單元測試經過後，再經過postman或者其餘工具來進行對外API接口層面的測試，作到全路徑覆蓋的測試，每每開發人員有一個思惟就是測試正常的業務流程，異常流程每每一律不考慮測試；然而出問題的都是那些異常的流程，單元測試須要遵照的原則以下：

• 儘量的全路徑覆蓋測試
• 拋棄本身寫的代碼思惟，當一個小白進行單元測試
• 關注異常路徑的單元測試
• 摒棄依賴思想，不要依賴聯調測試時間來進行測試，每每你開發只管開發，無論正確率，到後續測試聯調時間那就的瘋狂加班加點去趕進度了，還不能保證最佳的產品質量。