1.命名风格
abstract 通常用于业务逻辑类，base则是实体类，DO和VO类区分开是一个非常好的习惯，特别是在一些复杂的业务场景（虽然很多人不喜欢在名称后缀加DO，VO），虽然需要多加一步convert，但DefaultMapperFactory完全可以快速实现
我在之前的业务中好像有这么干过,仔细找了一下，发现好像是未遂。。。
private boolean notExecutionOnly=true;
这里实际上在说三种情况：1.普通方法命名太过简单，直接写为get/set，如果类里有字段，可能会造成误读。2.一个方法里的两个if（局部代码块）里面，局部变量在命名时不要一样，容易产生误解。3.子类的成员变量不能跟父类相同？？这里会报错吧–试了一下，并不会。
卑微，只用过几种不需要特殊说明的设计模式，默默地抛出了一个可能不会去看的大佬的解析。。。
https://blog.csdn.net/jiabailong/article/details/52289654
javadoc就是@author等标签，它可以输出到html文件中去
这里探讨了两个问题：SOA理念，接口命名
接口我最开始的理解是：形容能力的类，但后来使用得最多的还是controller里的service，这些service因为动态代理需要一个接口来作为中介，但我从内心里，并没有思考为这个接口是一个”形容能力的类“。
SOA：soa并不是一个编程上的规范，更多的像是一个设计的，架构的规范。
是构造分布式計算的应用程序的方法。它将应用程序功能作为服务发送给最终用户或者其他服务—但分布式计算有太多云平台，这个又啥用。
如果有人跟我扯这个，告辞。
定义常量
了解一下，虽然平时用的时候，很简单，但理解没有这么系统
枚举的应用范围还是很广的，基本上，常量的变化都是在我们常识范围内的，也都可以转换为枚举，只是有无必要而已。
代码格式
这个倒是很奇特，一般编程里很少有人这么干。
我个人理解，这一部分基本上是为了代码整洁，所以没有什么特别的理由，都统一的话，显然会更加优美。而且基本上都是在干死扣空格的活，我感觉啥时候进了大厂再说吧。
个人感觉，200行差不多，80行确实有点少，主方法抽出去几个大逻辑代码，再加点注释都不止80行了。但分清楚红花和绿叶确实是非常好的。
OOP规约
就像这样：Objects.equals(rate,rate+1); 这样的工具类还有很多，譬如判空。
double可以用equals吗？。。。很明显
精度问题一直都很严峻，要谨慎
显然，如果是updateTime，就可以用new date（）；当然也不符合这一条
神坑
特别是针对那些拆分地比较彻底的分布式项目，比如拆分出10几个乃至30几个模块，这个时候，通过idea来找寻方法的调用关系已经是非常困难了，基本上，一个方法如果是public，就不存在被删除的可能性了。