一、概述
在園子里面有很多關于各種技術細節的研究文章，都是比較牛逼的框架研究；但是一直沒有看到關于怎么樣提高開發效率的文章，大多提高開發效率的文章都是關于自動化等方面的輔助工具型別的，而不是開發中的一些小技巧；今天從編碼規范、編碼技巧、開發思想、設計模式等各方面的經驗來分享如何提高開發效率，
二、實際場景
在這個前后端分離盛行的開發年代，分工比較明確，開發者分前端開發者和后端開發者，然而感到欣慰的是.net 開發者大多是擔任著全堆疊開發的職責，有經驗的開發者都是從前端走過來的，說白了前端業務代碼對后端開發者來說那都不是事，
前后端分離前：幾年前前后端還未分離的時候，各種前端框架還未流行的時候，開發者的效率算是比較低下，后端干前端的活，甚至前端和后端夾雜作業，導致了作業開發容易亂，需要相互依賴，不能完全并行作業，這導致了開發效率底的一個極大的原因，同時開發出來的東西體驗也是很差，
前后端分離：職責分明，后端專注后端的開發，前端專注前端的開發；相互依賴關系很弱，后端可以先定義開發介面，前端頁面及mock 介面對接，最后聯調測驗時間前后端打通過；前后端完全可以并行開發，開發周期縮短一倍時間；不過這也就會導致了一個致命的問題，大多開發者只管自己的那一部分，不會以全域考慮，導致的一個問題就是聯調測驗時間代價太大,遇到問題相互甩鍋，
前后端都存在的問題，會再聯調測驗時間全部暴漏出來，這也是為什么聯調測驗時間會花費那么長時間，甚至晚上加班加點再處理問題的原因，總結如下：
- 開發程序中不夠謹慎，全是空例外問題
- 代碼不規范，代碼邏輯嵌套層次太深，
牽一發而動全身，以至于修改這里，爆露出那邊的問題出來，不會適當的解耦 - 后端介面回傳的欄位含義不明確，不清晰，甚至完全跟欄位含義違背，比如資料庫中有一個int 型別的Type欄位，而前端需要型別的中文名稱，后端開發者偷懶直接用Type 欄位回傳欄位中文名稱，后面前端需要int 型別的Type 有不知道加什么欄位為好，導致修修改改，影響效率，下面我會具體分享細節，
- 眼觀不足，不會考慮后續的需求變更擴展
- 沒有設計模式思想，導致維護成本變大
下面從幾個方面點來具體分析
三、空例外
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 的結果資料，多結合?. 和?? 運算子進行合理的邏輯處理，可以讓你的專案從此遠離空例外，
二、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
三、必要的設計模式
開發程序中不要一個鏈路寫到底，需要把某塊業務先想好，定位明確，該業務是應該屬于哪一塊，哪一類業務，后續可能會出現哪些方面的業務變動，適當的引入設計模式，那么多的設計模式，總有一個適合你當時開發的場景；
設計模式的選取需要對該模塊的作用及定義清晰，多思考，多歸類，自然而然心中就有了合適的設計模式的考量，
四、必要的單元測驗
做到每個方法單元測驗，最好是全路徑覆寫到每一條分支的單元測驗，先從小的方法單元測驗，底層的方法單元測驗通過后，再通過postman或者其他工具來進行對外API介面層面的測驗，做到全路徑覆寫的測驗，往往開發人員有一個思維就是測驗正常的業務流程，例外流程往往一概不考慮測驗；然而出問題的都是那些例外的流程，單元測驗需要遵守的原則如下：
- 盡可能的全路徑覆寫測驗
- 拋棄自己寫的代碼思維，當一個小白進行單元測驗
- 關注例外路徑的單元測驗
- 摒棄依賴思想，不要依賴聯調測驗時間來進行測驗，往往你開發只管開發，不管正確率，到后續測驗聯調時間那就的瘋狂加班加點去趕進度了，還不能保證最佳的產品質量，
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/4890.html
標籤：.NET Core