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 越简单的验证放在前面 这样后面的验证可以减少,能尽早返回