遵守這些原則讓你開發效率提高一倍
阿新 • • 發佈:2020-07-06
### 一、概述
在園子裡面有很多關於各種技術細節的研究文章,都是比較牛逼的框架研究;但是一直沒有看到關於怎麼樣提高開發效率的文章,大多提高開發效率的文章都是關於自動化等方面的輔助工具型別的,而不是開發中的一些小技巧;今天從編碼規範、編碼技巧、開發思想、設計模式等各方面的經驗來分享如何提高開發效率。
### 二、實際場景
在這個前後端分離盛行的開發年代,分工比較明確,開發者分前端開發者和後端開發者,然而感到欣慰的是.net 開發者大多是擔任著全棧開發的職責,有經驗的開發者都是從前端走過來的,說白了前端業務程式碼對後端開發者來說那都不是事。
`前後端分離前`:幾年前前後端還未分離的時候,各種前端框架還未流行的時候,開發者的效率算是比較低下,後端幹前端的活,甚至前端和後端夾雜工作,導致了工作開發容易亂,需要相互依賴,不能完全並行工作,這導致了開發效率底的一個極大的原因,同時開發出來的東西體驗也是很差。
`前後端分離`:職責分明,後端專注後端的開發,前端專注前端的開發;相互依賴關係很弱,後端可以先定義開發介面,前端頁面及mock 介面對接,最後聯調測試時間前後端打通過;前後端完全可以並行開發,開發週期縮短一倍時間;不過這也就會導致了一個致命的問題,大多開發者只管自己的那一部分,不會以全域性考慮,導致的一個問題就是聯調測試時間代價太大,遇到問題相互甩鍋。
前後端都存在的問題,會再聯調測試時間全部暴漏出來,這也是為什麼聯調測試時間會花費那麼長時間,甚至晚上加班加點再處理問題的原因,總結如下:
- 開發過程中不夠謹慎,全是空異常問題
- 程式碼不規範,程式碼邏輯巢狀層次太深,`牽一髮而動全身`,以至於修改這裡,爆露出那邊的問題出來,不會適當的解耦
- 後端介面返回的欄位含義不明確,不清晰,甚至完全跟欄位含義違背,比如資料庫中有一個int 型別的Type欄位,而前端需要型別的中文名稱,後端開發者偷懶直接用Type 欄位返回欄位中文名稱,後面前端需要int 型別的Type 有不知道加什麼欄位為好,導致修修改改,影響效率,下面我會具體分享細節。
- 眼觀不足,不會考慮後續的需求變更擴充套件
- 沒有設計模式思想,導致維護成本變大
下面從幾個方面點來具體分析
### 三、空異常
#### 1.1 不可信原則
作為開發者,你都可以把自己作為方法呼叫者的第三方,不需要去關注方法的實現,只需要關注呼叫方法我應該得到什麼結果;然而作為呼叫者第三方,你都需要認為實現者的方法都是不可信狀態,只需要秉承該原則,基本上你就跟空異常沒有緣分了.
#### 1.2 ?. (null條件運算子)
先來看一下以下程式碼:
```
[HttpGet]
public async Task> GetTest()
{
var list = GetList();//獲取List 列表
if (list?.Count <= 0)
{
return DataResponse.AsError("沒有獲取到資料");
}
//TODO 更新操作
return DataResponse.AsSuccess(true);
}
```
上面程式碼很多人可能會這麼寫,實際上是存在問題的list?.Count <=0 實際上在list 為空的時候就成了null<=0 判斷了,則也是false,不符合預期結果,正確的程式碼如下:
```
[HttpGet]
public async Task> GetTest()
{
var list = GetList();//獲取List 列表
if ((list?.Count??0) <= 0)
{
return DataResponse.AsError("沒有獲取到資料");
}
//TODO 更新操作
return DataResponse.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介面層面的測試,做到全路徑覆蓋的測試,往往開發人員有一個思維就是測試正常的業務流程,異常流程往往一概不考慮測試;然而出問題的都是那些異常的流程,單元測試需要遵守的原則如下:
- 儘可能的全路徑覆蓋測試
- 拋棄自己寫的程式碼思維,當一個小白進行單元測試
- 關注異常路徑的單元測試
- 摒棄依賴思想,不要依賴聯調測試時間來進行測試,往往你開發只管開發,不管正確率,到後續測試聯調時間那就的瘋狂加班加點去趕進度了,還不能保證最佳的產品質量。