周五进行了一次代码review，大部分业务问题和数据库设计问题在会上已经解决，但是代码质量(指的是封装，内聚，耦合，冗余，可读性，可测试性，javadoc)
提高空间还是很大，本文将从面向对象角度谈谈这个类的优缺点:
优点：
1 sonarlint扫描出来问题不多。大部分问题无痛关痒，5分钟内基本能改完。唯一注意的问题是方法圈复杂度过高。圈复杂度本质是需要切换过多思维理解代码，理论上一个圈复杂度就是一条代码路径，也就意味着加一个单元测试覆盖。
2 阿里p3c扫描出来问题也不多。才6个问题。值得注意的是“单个方法的总行数不超过80行”，这和sonarlint扫出来的是一样的。
3 Spotbug/FindBug扫出来0Bug.
4 IDEA INSPECT CODE 扫出来问题较多，327个，很多需要注意点，可以培养编程感觉，但是到达sonarlint和p3c已经不错了。
可见基本的编程感觉已经逐步养成。基本的逻辑处理没有太大问题。
缺点：
1 分层角度：FinancialInvitationStatsServiceImpl层Mapper，Service，RpcClient混合出现，出现顺序没有分类，势必导致一个上帝类的出现。
2 可读性角度：可读性不好的标记是：“code review时候会说，快过，我们不想知道你的细节”。别人花费很多天写的角度，怎么可能在review这么短时间理解呢？本质反映了抽象层次达不到可以阅读的水平，这反映了阅读者不知道代码到底做了什么，只能找
一些明显可见或者可改可不改的问题来review。牛顿三大定律理解起来很容易，这是抽象，但是在奥赛题中关于三大定律的题目会非常难，这是细节。这样对被review人代码设计水平提高有限， 大量的数据库查询出现在这个类中，而不是见名知意短方法，会加大阅读者点击无关类的次数。可以将细节屏蔽些，在同一抽象层次做逻辑处理。
3 职责划分：类的协作者过于多，但是真正对外api只有一个，虽然接口有5个公开方法，也就意味着一个类只有一个个方法，而这个方法内协作者有12个，理解起来会困难。可以尝试拆分类，拆分职责，而不是被一个mapper一个service这种模式所束缚。
4 内聚性：类的内聚性明显很低，一个标志就是调用了不同的微服务。可以看到编写者试图提取接口，但是这块更好的是提取类，职责太散，也是内聚性不够的标准， 方法内聚性也低，大部分方法其实用到了很少的实例变量，而是没有用到实例变量的也没有设计为静态方法。还是可以尝试划分类。
5 耦合性，内聚性不好的类，耦合性当然高了。非常多的协作者，会导致你的类变得脆弱。这个类和谁耦合了？
6 可测试性为0，测试覆盖率为0。难以测试，难以验证是这个类最大的问题。因为难以测试，想出一个验证条件很复杂。因为难以测试，导致可读性不高。因为难以测试，导致类的职责划分看不到….