代码最佳实践总结30条

1:对于不可以为空的对象,尽早返回,且打出错误日志.

    a:直观,易读,容易查找错误

    b:不会往下执行 能节约很多时间性能上的消耗

    c:不会引起一些未知性异常

2:对于接口返回 ,还是需要返回原生对象,而不是跟某个协议耦合.

   a:按照之前的逻辑使用PB返回,那么dubbo使用不了,其他的框架也是使用不了的

   b:如果把PB传到service里面,就会引起了很多跟业务逻辑不相关的一些代码,比如PB的封装.就会造成很混乱

  c:好处就是PB比较轻,但是因为 我们的service和web几乎都是局域网 ,所以不用考虑 加密  和体积大小问题 ,所以不管怎么样  还是传输java原生对象比较好

3: 对于接口返回CommonResponse,我个人觉得 也还是没有必要 

   a:一旦service返回这个CommonResponse,那么到了controller又要取出来做一些别的显示转换功能,这个类似java的封箱和拆箱了

   b:对于调用方来说,  根本不能直观的获得 CommonResponse里面的对象到底是什么,如果嵌套很深的话,更加难找,再如果使用了反射的话,那就更加不知道了

4: 对于接口返回HashMap,我个人认为弊端比较多

    a:hashMap返回的值,没人能清楚地知道 有多少,他们都是什么意思

   b:一旦我们去获取的时候就会存在 ,写错key?

    c: 查找出来为空的判断 各自强制类型转换 ?

   d:

5: 对于接口返回List<Object>或者Object,也是有很多弊端的

   a:对于接口返回这样的类型,那么调用方  看到这个方法应该怎么办,怎么用?

   b:这样的接口类型 ,最好还是应该使用泛型 ,对于自己写代码的时候也会尽快发现错误.

6:对于接口的返回处理,如果执行成功了,就直接默认成功,不处理, 如果失败了就会有异常机制往外抛出去

   a:之前看到很多接口 ,在每个if else 里面,如果成功就返回 CommonResponse  Success,其实这个是没有必要的,比如一百个if else 就写了一百遍 ，默认成功之后 统一处理

   b:而且失败了 最好不要返回错误 ，直接抛出业务异常 ，不然 根本无法定位错误 

7:对于异常的处理

   a:一些不重要的,比如订单流程 发邮件失败  可以catch住 ,因为这个不能影响主流程

   b:但是对于主流程的异常还是需要一步步往外面抛出去,之前看到很多异常被catch,住了   但是又没有往外面抛  

   c:所以现在对于异常得处理，如果是业务异常或者不是必须catch住的就直接抛出去， 如果是那些读文件的。就可以先catch住，然后关闭流，再抛出去

   d:这样的异常最后都会到一个统一的出口 。做同一转换 

8：对于多个地方出现的一样的字符串，最好还是同意使用常量来管理 

9:对于接口的定义,能一个方法搞定的最好 一个方法搞定  直接传输对象进去

    a:比如一个修改订单的状态,价格,时间等等的方法 就在Service写了3个. 其实这个应该在controller来控制,不然方法也是会指数级别增长

    b:

10：对于业务逻辑复杂的方法，应该尽量抽出小方法，减少if else ， 比如之前订单的一个方法  300 多行 if  else 里面夹带了发短信  发邮件  发微信模板

11： 对于if  else 比较多的业务  不仅仅要独立小方法  而且要减少if else   比如 订单的各种状态  发不同的消息   我们 可以把他放到统一hashMap 里面 

根据不同状态获取不同信息   且时间复杂度为1

12:有些业务逻辑删除关联关系有外键关联,导致删除不掉.应该抛出业务异常

13：:还是要把核心service写成一个独立的方法,不然app和web很难维护

14：pb的转换写成功一个单独的pbConvert. 写成模板模式比较好理解,而且不容易出错,能复用

15：工具类最好先统一，多用工具类好维护，bug少

16 最好传值得时候使用封装类型，这样就不会有默认值，如果是空，就是没有传。所以在接受前端参数的时候，最好用封装类型，

而在比较大小，或者存redis的key 的时候必须用原始类型 否则 会获得错误的结果   因为封装类型值相等 但是对象不等

17:最好每个方法还是需要写一下junit单元测试，这样会减少bug和以后容易找问题

18;注意一些性能的小优化，今天一个改变订单状态的接口超时了，想想应该把发邮件和发短信等等的写成异步发送

19:代码里面尽量减少循环，特别是双重循环(现在还有很多3重循环)，可以把他放到hashmap里面。

20:logback看看怎么优化比较好  按照每天的日志文件  每天又分为info  sql error等等

21:在每个比较关键的代码的执行点，最好都带一个log，这样能更好的查找问题

22:对于check的方法，比如checktoken  最好是只返回true false。如果类型比较多，就返回枚举类型。或者采用异常机制(各种 返回 1  2  3  4 5 6 简直看不懂)

23:是否有必要分 bo vo po，dto等等类型转换

vo :这个是web层，请求的参数， 这个对象，专门用来接收参数，以及判断字段的正确性

dto：这个专门用来做对象传输用 ， 因为请求的参数和最终存入数据库的 是不同的 ，且查询数据库出来的时候  还会冗余很多查询信息

po：这个专门跟数据库字段一一对应， ORM对应存入数据库的 

24:对于分层思想  Service层之间尽量不要去调用别的层的dao   比如 orderService 里面有userDao，而且controller里面更加不能调用userDao

25 对于每个接口实现  最后返回 对象  而不是NULL  (effect in java),比如 list   返回一个长度为0的arraylist.

26:能在controller判断的就尽早返回  减少远程调用

27:远程调研可以写批量接口 

28 越简单的验证放在前面   这样后面的验证可以减少,能尽早返回

转载于:https://my.oschina.net/jwayGod/blog/534942