[Asp.NetCore]如何提高開發(fā)效率-創(chuàng)新互聯(lián)

這篇文章主要講解了“[Asp.Net Core]如何提高開發(fā)效率”，文中的講解內(nèi)容簡(jiǎn)單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“[Asp.Net Core]如何提高開發(fā)效率”吧！

創(chuàng)新互聯(lián)專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務(wù)，包含不限于網(wǎng)站設(shè)計(jì)制作、做網(wǎng)站、黃埔網(wǎng)絡(luò)推廣、小程序設(shè)計(jì)、黃埔網(wǎng)絡(luò)營(yíng)銷、黃埔企業(yè)策劃、黃埔品牌公關(guān)、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運(yùn)營(yíng)等，從售前售中售后，我們都將竭誠(chéng)為您服務(wù)，您的肯定，是我們大的嘉獎(jiǎng)；創(chuàng)新互聯(lián)為所有大學(xué)生創(chuàng)業(yè)者提供黃埔建站搭建服務(wù)，24小時(shí)服務(wù)熱線：18982081108，官方網(wǎng)址：muchs.cn

一、概述

在園子里面有很多關(guān)于各種技術(shù)細(xì)節(jié)的研究文章，都是比較牛逼的框架研究；但是一直沒有看到關(guān)于怎么樣提高開發(fā)效率的文章，大多提高開發(fā)效率的文章都是關(guān)于自動(dòng)化等方面的輔助工具類型的，而不是開發(fā)中的一些小技巧；今天從編碼規(guī)范、編碼技巧、開發(fā)思想、設(shè)計(jì)模式等各方面的經(jīng)驗(yàn)來分享如何提高開發(fā)效率。

二、實(shí)際場(chǎng)景

在這個(gè)前后端分離盛行的開發(fā)年代，分工比較明確，開發(fā)者分前端開發(fā)者和后端開發(fā)者，然而感到欣慰的是.net 開發(fā)者大多是擔(dān)任著全棧開發(fā)的職責(zé)，有經(jīng)驗(yàn)的開發(fā)者都是從前端走過來的，說白了前端業(yè)務(wù)代碼對(duì)后端開發(fā)者來說那都不是事。

前后端分離前：幾年前前后端還未分離的時(shí)候，各種前端框架還未流行的時(shí)候，開發(fā)者的效率算是比較低下，后端干前端的活，甚至前端和后端夾雜工作，導(dǎo)致了工作開發(fā)容易亂，需要相互依賴，不能完全并行工作，這導(dǎo)致了開發(fā)效率底的一個(gè)極大的原因，同時(shí)開發(fā)出來的東西體驗(yàn)也是很差。

前后端分離：職責(zé)分明，后端專注后端的開發(fā)，前端專注前端的開發(fā)；相互依賴關(guān)系很弱，后端可以先定義開發(fā)接口，前端頁(yè)面及mock 接口對(duì)接，最后聯(lián)調(diào)測(cè)試時(shí)間前后端打通過；前后端完全可以并行開發(fā)，開發(fā)周期縮短一倍時(shí)間；不過這也就會(huì)導(dǎo)致了一個(gè)致命的問題，大多開發(fā)者只管自己的那一部分，不會(huì)以全局考慮，導(dǎo)致的一個(gè)問題就是聯(lián)調(diào)測(cè)試時(shí)間代價(jià)太大,遇到問題相互甩鍋。

前后端都存在的問題，會(huì)再聯(lián)調(diào)測(cè)試時(shí)間全部暴漏出來，這也是為什么聯(lián)調(diào)測(cè)試時(shí)間會(huì)花費(fèi)那么長(zhǎng)時(shí)間，甚至晚上加班加點(diǎn)再處理問題的原因，總結(jié)如下：

• 開發(fā)過程中不夠謹(jǐn)慎，全是空異常問題

• 代碼不規(guī)范，代碼邏輯嵌套層次太深，牽一發(fā)而動(dòng)全身，以至于修改這里，爆露出那邊的問題出來，不會(huì)適當(dāng)?shù)慕怦?/p>

• 后端接口返回的字段含義不明確，不清晰，甚至完全跟字段含義違背，比如數(shù)據(jù)庫(kù)中有一個(gè)int 類型的Type字段，而前端需要類型的中文名稱，后端開發(fā)者偷懶直接用Type 字段返回字段中文名稱，后面前端需要int 類型的Type 有不知道加什么字段為好，導(dǎo)致修修改改，影響效率，下面我會(huì)具體分享細(xì)節(jié)。

• 眼觀不足，不會(huì)考慮后續(xù)的需求變更擴(kuò)展

• 沒有設(shè)計(jì)模式思想，導(dǎo)致維護(hù)成本變大

  
  

下面從幾個(gè)方面點(diǎn)來具體分析

三、空異常

1.1 不可信原則

作為開發(fā)者，你都可以把自己作為方法調(diào)用者的第三方，不需要去關(guān)注方法的實(shí)現(xiàn)，只需要關(guān)注調(diào)用方法我應(yīng)該得到什么結(jié)果；然而作為調(diào)用者第三方，你都需要認(rèn)為實(shí)現(xiàn)者的方法都是不可信狀態(tài)，只需要秉承該原則，基本上你就跟空異常沒有緣分了.

1.2 ?. （null條件運(yùn)算符）

先來看一下以下代碼：

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

上面代碼很多人可能會(huì)這么寫，實(shí)際上是存在問題的list?.Count <=0 實(shí)際上在list 為空的時(shí)候就成了null<=0 判斷了，則也是false，不符合預(yù)期結(jié)果，正確的代碼如下：

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

這里就引用了?? 運(yùn)算符（空合并運(yùn)算符）

1.3 ?? （空合并運(yùn)算符）

MSDN上面的解釋：?? 運(yùn)算符稱為 null 合并運(yùn)算符，用于定義可以為 null 值的類型和引用類型的默認(rèn)值。如果左操作數(shù)不為 null，則此返回左操作數(shù)；否則當(dāng)左操作數(shù)為 null，返回右操作數(shù)。

1.4 如何遠(yuǎn)離空異常？

秉承原則：不可信原則，什么是不可信原則呢？你調(diào)用方法都任務(wù)改方法是不可信的，包括自己寫的方法；這在敏捷快速開發(fā)中更明顯，特別是調(diào)用團(tuán)隊(duì)中別人開發(fā)的微服務(wù)api ，你不需要關(guān)注方法的實(shí)現(xiàn)，只需要關(guān)注方法的結(jié)果即可，但是也不能太過于相信它；所有的返回結(jié)果你都需要判斷是否是null 的結(jié)果數(shù)據(jù)，多結(jié)合?. 和?? 運(yùn)算符進(jìn)行合理的邏輯處理，可以讓你的項(xiàng)目從此遠(yuǎn)離空異常。

四.If else 解套

先來看一看比較有趣的網(wǎng)絡(luò)上的圖片

取反原則

對(duì)于上面的if else 嵌套業(yè)務(wù)大家是不是經(jīng)常遇到，看到這種代碼會(huì)非常的頭疼，難于維護(hù)，影響開發(fā)效率，同時(shí)也容易出現(xiàn)bug。有經(jīng)驗(yàn)的開發(fā)者必定會(huì)對(duì)上面這段代碼進(jìn)行優(yōu)化，我的經(jīng)驗(yàn)是取反原則。

什么是取反原則呢？把不符合的條件先 return 下去，到最后留下符合條件的邏輯，這就是取反原則，一眼看下來就只有一層嵌套，不會(huì)存在多層嵌套。

我們來看下我遇到的實(shí)際場(chǎng)景代碼，源代碼大體如下：

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
}

取反原則優(yōu)化后的代碼如下：

 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

五、必要的設(shè)計(jì)模式

開發(fā)過程中不要一個(gè)鏈路寫到底，需要把某塊業(yè)務(wù)先想好，定位明確，該業(yè)務(wù)是應(yīng)該屬于哪一塊，哪一類業(yè)務(wù)，后續(xù)可能會(huì)出現(xiàn)哪些方面的業(yè)務(wù)變動(dòng)，適當(dāng)?shù)囊朐O(shè)計(jì)模式，那么多的設(shè)計(jì)模式，總有一個(gè)適合你當(dāng)時(shí)開發(fā)的場(chǎng)景；

設(shè)計(jì)模式的選取需要對(duì)該模塊的作用及定義清晰，多思考，多歸類，自然而然心中就有了合適的設(shè)計(jì)模式的考量。

六、必要的單元測(cè)試

做到每個(gè)方法單元測(cè)試，好是全路徑覆蓋到每一條分支的單元測(cè)試，先從小的方法單元測(cè)試，底層的方法單元測(cè)試通過后，再通過postman或者其他工具來進(jìn)行對(duì)外API接口層面的測(cè)試，做到全路徑覆蓋的測(cè)試，往往開發(fā)人員有一個(gè)思維就是測(cè)試正常的業(yè)務(wù)流程，異常流程往往一概不考慮測(cè)試；然而出問題的都是那些異常的流程，單元測(cè)試需要遵守的原則如下：

• 盡可能的全路徑覆蓋測(cè)試

• 拋棄自己寫的代碼思維，當(dāng)一個(gè)小白進(jìn)行單元測(cè)試

• 關(guān)注異常路徑的單元測(cè)試

• 摒棄依賴思想，不要依賴聯(lián)調(diào)測(cè)試時(shí)間來進(jìn)行測(cè)試，往往你開發(fā)只管開發(fā)，不管正確率，到后續(xù)測(cè)試聯(lián)調(diào)時(shí)間那就的瘋狂加班加點(diǎn)去趕進(jìn)度了，還不能保證很好的產(chǎn)品質(zhì)量。

感謝各位的閱讀，以上就是“[Asp.Net Core]如何提高開發(fā)效率”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對(duì)[Asp.Net Core]如何提高開發(fā)效率這一問題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是創(chuàng)新互聯(lián)網(wǎng)站建設(shè)公司，，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！

本文名稱：[Asp.NetCore]如何提高開發(fā)效率-創(chuàng)新互聯(lián)
鏈接URL：http://muchs.cn/article18/deihgp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供Google、網(wǎng)站營(yíng)銷、定制網(wǎng)站、標(biāo)簽優(yōu)化、移動(dòng)網(wǎng)站建設(shè)、網(wǎng)站設(shè)計(jì)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)