网站开发项目总结报告,做网站毕业设计存在的问题,wordpress缩略图默认尺寸怎么修改,好网站你知道的一、概述在园子里面有很多关于各种技术细节的研究文章#xff0c;都是比较牛逼的框架研究#xff1b;但是一直没有看到关于怎么样提高开发效率的文章#xff0c;大多提高开发效率的文章都是关于自动化等方面的辅助工具类型的#xff0c;而不是开发中的一些小技巧#xff1… 一、概述在园子里面有很多关于各种技术细节的研究文章都是比较牛逼的框架研究但是一直没有看到关于怎么样提高开发效率的文章大多提高开发效率的文章都是关于自动化等方面的辅助工具类型的而不是开发中的一些小技巧今天从编码规范、编码技巧、开发思想、设计模式等各方面的经验来分享如何提高开发效率。二、实际场景在这个前后端分离盛行的开发年代分工比较明确开发者分前端开发者和后端开发者然而感到欣慰的是.net 开发者大多是担任着全栈开发的职责有经验的开发者都是从前端走过来的说白了前端业务代码对后端开发者来说那都不是事。前后端分离前几年前前后端还未分离的时候各种前端框架还未流行的时候开发者的效率算是比较低下后端干前端的活甚至前端和后端夹杂工作导致了工作开发容易乱需要相互依赖不能完全并行工作这导致了开发效率底的一个极大的原因同时开发出来的东西体验也是很差。前后端分离职责分明后端专注后端的开发前端专注前端的开发相互依赖关系很弱后端可以先定义开发接口前端页面及mock 接口对接最后联调测试时间前后端打通过前后端完全可以并行开发开发周期缩短一倍时间不过这也就会导致了一个致命的问题大多开发者只管自己的那一部分不会以全局考虑导致的一个问题就是联调测试时间代价太大,遇到问题相互甩锅。前后端都存在的问题会再联调测试时间全部暴漏出来这也是为什么联调测试时间会花费那么长时间甚至晚上加班加点再处理问题的原因总结如下开发过程中不够谨慎全是空异常问题代码不规范代码逻辑嵌套层次太深牵一发而动全身以至于修改这里爆露出那边的问题出来不会适当的解耦后端接口返回的字段含义不明确不清晰甚至完全跟字段含义违背比如数据库中有一个int 类型的Type字段而前端需要类型的中文名称后端开发者偷懒直接用Type 字段返回字段中文名称后面前端需要int 类型的Type 有不知道加什么字段为好导致修修改改影响效率下面我会具体分享细节。眼观不足不会考虑后续的需求变更扩展没有设计模式思想导致维护成本变大 下面从几个方面点来具体分析三、空异常1.1 不可信原则作为开发者你都可以把自己作为方法调用者的第三方不需要去关注方法的实现只需要关注调用方法我应该得到什么结果然而作为调用者第三方你都需要认为实现者的方法都是不可信状态只需要秉承该原则基本上你就跟空异常没有缘分了.1.2 ?. null条件运算符先来看一下以下代码 [HttpGet]public async TaskDataResponsebool GetTest(){var list GetList();//获取List 列表if (list?.Count 0){return DataResponsebool.AsError(没有获取到数据);}//TODO 更新操作return DataResponsebool.AsSuccess(true);}
上面代码很多人可能会这么写实际上是存在问题的list?.Count 0 实际上在list 为空的时候就成了null0 判断了则也是false不符合预期结果正确的代码如下 [HttpGet]public async TaskDataResponsebool GetTest(){var list GetList();//获取List 列表if ((list?.Count??0) 0){return DataResponsebool.AsError(没有获取到数据);}//TODO 更新操作return DataResponsebool.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 sometingreturn;}if (!condition1){// do sometingreturn;}if (!condition2){// do sometingreturn;}if(!condition3){// do sometingreturn;}if(!condition4){// do sometingreturn;}// do someting
三、必要的设计模式 开发过程中不要一个链路写到底需要把某块业务先想好定位明确该业务是应该属于哪一块哪一类业务后续可能会出现哪些方面的业务变动适当的引入设计模式那么多的设计模式总有一个适合你当时开发的场景设计模式的选取需要对该模块的作用及定义清晰多思考多归类自然而然心中就有了合适的设计模式的考量。四、必要的单元测试 做到每个方法单元测试最好是全路径覆盖到每一条分支的单元测试先从小的方法单元测试底层的方法单元测试通过后再通过postman或者其他工具来进行对外API接口层面的测试做到全路径覆盖的测试往往开发人员有一个思维就是测试正常的业务流程异常流程往往一概不考虑测试然而出问题的都是那些异常的流程单元测试需要遵守的原则如下尽可能的全路径覆盖测试抛弃自己写的代码思维当一个小白进行单元测试关注异常路径的单元测试摒弃依赖思想不要依赖联调测试时间来进行测试往往你开发只管开发不管正确率到后续测试联调时间那就的疯狂加班加点去赶进度了还不能保证最佳的产品质量。
