allbetgmaing客户端下载:遵守这些原则让你开发效率提高一倍

admin 4个月前 (07-06) 科技 43 0

一、概述

在园子内里有许多关于种种技术细节的研究文章,都是对照牛逼的框架研究;然则一直没有看到关于怎么样提高开发效率的文章,大多提高开发效率的文章都是关于自动化等方面的辅助工具类型的,而不是开发中的一些小技巧;今天从编码规范、编码技巧、开发头脑、设计模式等各方面的履历来分享若何提高开发效率。

二、现实场景

在这个前后端星散盛行的开发年月,分工对照明确,开发者分前端开发者和后端开发者,然而感应欣慰的是.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接口层面的测试,做到全路径笼罩的测试,往往开发人员有一个头脑就是测试正常的营业流程,异常流程往往一概不思量测试;然而出问题的都是那些异常的流程,单元测试需要遵守的原则如下:

  • 尽可能的全路径笼罩测试
  • 甩掉自己写的代码头脑,当一个小白举行单元测试
  • 关注异常路径的单元测试
  • 摒弃依赖头脑,不要依赖联调测试时间来举行测试,往往你开发只管开发,不管准确率,到后续测试联调时间那就的疯狂加班加点去赶进度了,还不能保证最佳的产品质量。
,

欧博亚洲

欢迎进入欧博亚洲(Allbet Game):www.aLLbetgame.us,欧博官网是欧博集团的官方网站。欧博官网开放Allbet注册、Allbe代理、Allbet电脑客户端、Allbet手机版下载等业务。

皇冠体育声明:该文看法仅代表作者自己,与本平台无关。转载请注明:allbetgmaing客户端下载:遵守这些原则让你开发效率提高一倍

网友评论

  • (*)

最新评论

文章归档

站点信息

  • 文章总数:632
  • 页面总数:0
  • 分类总数:8
  • 标签总数:973
  • 评论总数:201
  • 浏览总数:8646