其他分享
首页 > 其他分享> > Code 优化篇

Code 优化篇

作者:互联网

Code优化注意事项

前言

项目开发已经进入到后期了,根据之前给同事发的Code开发规范邮件,再梳理一遍做个笔记记录下来,Code是公司项目比较敏感所以不会上Code 直接口述。

正文

1.第三方引用 

第三方引用包应该固定到某一个微服务下,添加DTO类来代替第三方类在项目中完成交互.

因为目前做的这个项目很大,本身业务很复杂,12个微服务,各种第三方集成,发现前期很多开发直接调用第三方类,导致每个微服务中都会引用第三方package,如果有第三方类有变动的话,波及的范围太大,所以把这个第三方集成限制到一个service中,通过DTO类进行交互,极大地提升了后期的维护成本、

2.EF Core

我们项目是通过EF Core与DB进行交互的,体验很好,开发用SQL Server 云上用pgAdmin。

没有直接写SQL语句,通过EF Core来交互,节省了大量的DB查询操作,省力的同时缺点就是查询的数据没有那么简洁,Tracking机制也极大地影响了查询效率.
之前在EF core篇就解释了他的一些特性和tracking机制 这里就不多说了。
几个开发过程中注意的点:

3.Cache的使用

NoSQL本来的使用的场景就是减少DB交互,快速响应,问题是很多开发无脑的使用Cache,我做过一个测试就是一个简单的查询,DB的响应速度绝不比Cache慢。Cache 应该没用在多次重复调用不频繁更改的数据时,比如导航栏,下拉框等地方,涉及到业务逻辑的地方,一定要考虑清楚再使用.

4.log的添加

这个没什么说的只有没经过bug毒打的人的才认为这玩意没啥用,维护的时候全靠log续命.
问题就是项目中很多新人,导致对log 没什么敬畏,加了很多无用的log,只是应付工作,根本没有起到记录重要信息的作用。

凡是涉及到更改数据的地方,都应该加上log,这个没什么说的,
重点是log中应该记录什么信息,首先页面上能够获取的信息(比如Name),Exception 的堆栈信息(这里提示一下,Exception.Message是没有堆栈信息的,几乎没什么用,可以使用Tostring或者直接Exception都可以)
Data的主键(方便查询),当添加以上信息时还有一个点就是,注意以上信息的 NullOrEmpty判断,就这个项目的开发过程就见过太多,catch中log报错的情况。.

5.API返回值-错误信息

严格来说,一个正经的项目当API报错时,不允许返回Exception给前台页面,Exception的信息对用户来说应该是不可见的,在开发过程中,没说过这个事,后来在review Code的时候发现 很多人都没有加 这个处理,直接return Exception
请准备一个词条(经过国际化的),返回来,如果就是不知道写啥,就写发生未知错误,请联系管理员.emmm

 

6.效率优化

不需要讨论Code的简洁性,如果要求太严格可能项目都没法推进,单纯的一点就是
循环中一定不要查询DB或者调用第三方的方法之类的(包括Event和gRPC),请一定要挪到循环外边,将所需要的数据一次性查完,在内存中进行filter调用,循环中应该只是业务逻辑的处理,
这一点尽管从项目开始就在强调,结果还是不尽人意。

 

7.异步

我们开发项目使用的是.net Core 新加的一个机制就是API async,好处就是会提升项目的吞吐量,缺点是CPU(线程)会占用的比较多,包括EF Core 层面的异步
这会导致两个比较常见的问题:
1.DBContext被dispose掉了原因:主线程执行完了(DBContext生命周期一般都是Scoped)子线程需要调用DBContext 的时候发现没了,
2.同一个DBCOntext被多个线程同时调用:就是字面意思了,只能添加await了.
添加异步会提升很多东西,但是对开发人员的要求也在提高,ref out 全部失效,委托,await 等等
委托用的一般比较少举个最常见的例子就是 foreach 单线程时将foreach写成委托的形式没区别,但是多线程问题就多了,由此也引起了我们对DEV的另一个要求就是,别炫技,就是写最朴实的code,因为没办法确定这个项目之后维护的人的水平,尽可能的减少维护成本
ps:我见过贼恶心的 炫技就是switch case,第一眼看过去竟然没看懂。。。

 

 




 

标签:Exception,Code,log,DB,查询,优化,第三方
来源: https://www.cnblogs.com/SGwanmin/p/16573120.html