序：入职大公司已经有一段时间了，但是小组每次进行code review 都能找出来好多问题，这篇博客主要针对如何写好一个类一个方法所写，工程师应该有工匠精神，不断的对自己的代码进行优化，往往有意想不到的惊喜，我想这就是工作本身的魅力，愿自己心存感恩，不忘初心，做一件事都能细细雕琢。
对一个类和类中方法的优化总结
（1）短路写法
说道java短路你会想到什么，短路 && ，短路或 || ，没错开发中注意更好的应用他们能提高不少代码的效率
eg：
（1）当（方法(boolean)1 || 方法(boolean)2）时，返回方法(boolean)1 返回true 的时候,方法(boolean)2 的逻辑是不会执行的
（2）当（方法(boolean)1 &&方法(boolean)2）时，返回方法(boolean)1 返回false的时候,方法(boolean)2 的逻辑是不会执行的
我们这里说的短路写法和这个类似
//业务校验方法
User user = getUser();
if (user != null){
//你的业务逻辑
//你的业务逻辑
//你的业务逻辑
//你的业务逻辑
//你的业务逻辑
//你的业务逻辑
String realName = user.getRealName()
if (realName != null){
//你的业务逻辑
//你的业务逻辑
//你的业务逻辑
// 成功处理
}else {
//失败处理
}
}
//失败处理能看出来这样代码的问题嘛？
（1）多重嵌套，工作中的逻辑常常比这更复杂，，往往过段时间别说其他同事了，自己都不愿意看自己的代码
（2）返回结果不可追溯（到处都有），不能一下子看出理解方法哪里是正确的结果，哪里是失败的结果
这样代码如何重写
首先我们应该梳理我们的业务流程，下图是我模拟工作的一个流程图
按照上图的代码上面的伪代码优化如下：
//业务校验方法
User user = getUser();
if (user == null){
//失败处理;
}
//你的业务逻辑
//你的业务逻辑
//你的业务逻辑
//你的业务逻辑
//你的业务逻辑
//你的业务逻辑
String realName = user.getRealName()
if (realName = null){
//失败处理
}
//你的业务逻辑
//你的业务逻辑
//你的业务逻辑
//想要的结果返回如上代码，你的业务都是可以写成私有方法的，而且逻辑都是平行的，这和微服务的设计理念是相符合的（个人见解可以忽略），逻辑平行，逻辑解耦，代码清晰。
（2）对写一个业务接口的个人见解
好的业务接口实现逻辑，应该是可配置的，换句话说只要是写代码就应该把可配置化这个思维放在首要的思考位置，例子 ：你要进行一个用户操作（比如用户登录），其中用到用户认证（第三方服务），最后更新用户数据库操作，这个例子可以参考上面的流程图
重点： 当你把用户认证相关的参数拼装，接口接口调用，返回结果处理等等一系列操作写在用户登录的相关逻辑放在一个方法里，显然是不合适的，当然将用户认证相关的参数拼装，接口接口调用，返回结果处理等一系列操作 放在一系列操作一起（用户认证方法）看似是服务 **将各自逻辑放在各自的维度下（用户认证只做用户认证）**这样的做法是合理的，但是最终还是被同事批评了，因为我们的服务用写单测，这样写第三方调用逻辑，返回结果处理部分的逻辑就落到了第三方获取透传层，像我上面的想法最终写单测的时候，第三方调用层是必须被单测覆盖到的，所以我最终的处理方法是将最终的第三方处理单独的写成一层在对应的用户service下（一个方法），这样单测覆盖用户service 就好了，下面是我代码现在的实现思路，欢迎多多指点
(3) 学会模仿，模仿的成本最小，出错概率也最小
代码优化，自然随之的风险，我基本同意一提到优化，上手就干，也不提倡保持原有能用就是，优化要就行，就必须规避风险，如何有限规避风险那，
我认为
此处划重点
(1)首先要读懂原有代码，形成自己的思维设计
(2) 自己不懂得，无法确认的东西不要碰，模仿就好
eg: if(result.isSuccess() && result.getCode == CodeEnum.sucess){
}
这样的代码不能确认不要动 ，因为貌似 result.isSuccess()，就能cover的住结果，然而那，你不晓得结果的设计者会不会给你留坑，所以这样的代码不要动
(3) 修改或变成，最终的逻辑可靠性，不要用眼看，要用数据说话，正向逻辑，反向逻辑，为空逻辑 都要测一测
最后一句话：记得对自己的代码负责，所以一定要细细打磨
