序
总体来说我的写代码风格，基本和手册上差不多。但是还有不少地方有细微的区别。
特别有感悟的地方说一下。对应开发手册标号
一。
1.1在变量名中不用任何特殊符号，这点确实影响阅读理解。
2.不允许拼音，这点我就是尽量保持，但是不能完全做到，比如。我们的副本：过关斩将，这玩意要我怎么翻译成英文。
1.12具体模式，一版能想起来是模式就写下，但是很多情况，比如事件监听就不写了。
1.15枚举我习惯是E****Type的命名方式，内部字段使用常规变量驼峰式写法。
1.16数据一版以Data为后缀，模板数据以Model为后缀
补充下，我的同事再给变量起名时，相对功能变量中的一个，和另一个不怎么相关的逻辑用的互为反义词，现在想起来还生气。
在此记录这事为，我认为是基础，所有人都会做的事。居然在其他人那居然无法做到。
二
2.long型赋值确实结尾大写L很好用，虽然我一般都不写。
4.分层应用这点写的比较好，我之前是一个统一的包，总觉得有些不合适。但是说不上来。这里完美的解释了。
三
代码格式其实我并没有仔细看，我的要求是，提交前使用eclipse自动排版。
四
3.可变参数，这个东西主要用于发提示的参数，记日志时的参数，别的用的基本没有。
4.不能使用过时的方法，有些方法虽然过时了，但是他很好用。只能是尽量不用。如果有替代就用替代，没替代就没办法了。
7.包装类型的比较，我一般是Integer就intValue(）去比较，严禁直接比较对象是一个。
8.所有的POJO类属性必须使用包装数据类型，这点很好，很久以前我已经改为这样了。
9.【强制】定义DO/DTO/VO等POJO类时，不要设定任何属性默认值。重点，实体不要设置默认属性，否则不知道是后赋值还是默认的，很容易被坑。
11.【强制】构造方法里面禁止加入任何业务逻辑，如果有初始化逻辑，请放在init方法中。我见过的很多代码都在构造方法里有逻辑，但是我个人还是比较反对这点。一般是构造完，调用init构造过程中，容易出坑、
13.早就这么干了，有被坑过。
五
1.3一般也就是枚举，String，Integer 这种作为map的key
6.<? extendsT>这个写法我经常这么干，<? extendsT>貌似用的极少。
8.有被坑过。
11.有被坑过，ConcurrentHashMap 用null get也会报错。
六
1.说一下，乐观锁是个很好的解决方式
4【强制】线程池不允许使用Executors去创建，而是通过ThreadPoolExecutor的方式，这样的处理方式让写的同学更加明确线程池的运行规则，规避资源耗尽的风险。说明：Executors返回的线程池对象的弊端如下：1）FixedThreadPool和SingleThreadPool:允许的请求队列长度为Integer.MAX_VALUE，可能会堆积大量的请求，从而导致OOM。2）CachedThreadPool和ScheduledThreadPool:允许的创建线程数量为Integer.MAX_VALUE，可能会创建大量的线程，从而导致OOM。
全占过来，避免忘了，是很好的方式。
5.可用threadlock解决，又是一个十分好用的神奇类。
6.对高并发，线程安全，方式很多，比如我常用的，对单个用户保证只有一个线程去处理。
7.专门做过类似的加锁处理，比如a，b两个锁，没有a锁的情况，无法获取到b锁。
8.【强制】并发修改同一记录时，避免更新丢失，需要加锁。要么在应用层加锁，要么在缓存加锁，要么在数据库层使用乐观锁，使用version作为更新依据。说明：如果每次访问冲突概率小于20%，推荐使用乐观锁，否则使用悲观锁。乐观锁的重试次数不得小于3次。
我的锁基本都是放在了应用层，极力避免在数据库加锁，因为我要快速响应，所以都是异步存数据库，必须保证数据层尽量高的成功可能性。
9.但是ScheduledExecutorService不太好保证时序，所以还是在所有功能加捕获异常。
10.【推荐】使用CountDownLatch进行异步转同步操作。有学到，异步转同步，我在设计rpc时头疼了好久。
11.ThreadLocalRandom又学到，我之前都是Math.random()
12.我经常这么写，看来是有问题。
13.LongAdder又有新知识。另外我一般都是一写1.5读
七
2.我就是这么干的，我也是这么要求的。
3.正常都用return，如果接下来还有逻辑，那就只能else if
4.if中不要超过3个，否则单独抽取方法，我就这样干的。当年一个if中7个判定，没看懂，果断抽方法。
八
1.、/**类用来干嘛*/特别有用。
3.我都是写，创造者，经常不写日期
6.一切以能看懂为原则，越白话越好。
九
2.编译器自动添加的方法，很好用
4.学到。
5.推荐使用Instant类
异常处理
一
1.当年看到直接取list第一个值，然后catch，气得不行。现在想想还是很气。为什么报错不知道吗，明明是个空list还取。不知道判定为空么。当然这个list获取的也不对，不知道根据主键获取单一实体么，还要用example获取list。
2.刚入行框架里有这么个写法，过了几年再想想，逊毙了。
4.这点确实没做那么好，我只是全做日志记录了，不少代码其实没处理。或者我认为不会出错。还有一次些，做成提示扔给用户了。
5.尽量保证不在数据层出问题。否则及时响应可能不太好处理。
6.try-with-resources方式。没用过，可以试试。
9.返回null，就是为了节省资源，很好用。
二
1，还有人直接调日志api？严禁直接调用日志api写日志。只允许使用门面类。
2.一般为2个月。
4.我一般是占位符。is如果改级别，略有麻烦。
6.【强制】异常信息应该包括两类信息：案发现场信息和异常堆栈信息。如果不处理，那么通过关键字throws往上抛出。正例：logger.error(各类参数或者对象toString + "_" + e.getMessage(), e);
三
以后要重视单元测试了。
四
就是道德规范，
五
一
2.MySQL在Windows下不区分大小写，但在Linux下默认是区分大小写。因此，数据库名、表名、字段名，都不允许出现任何大写字母，避免节外生枝。
好像给自己挖坑了。但是没什么问题。
4.用了就是给自己挖坑。
5.【强制】主键索引名为pk_字段名；唯一索引名为uk_字段名；普通索引名则为idx_字段名。说明：pk_ 即primary key；uk_ 即uniquekey；idx_ 即index的简称。
以前还真没在意这个。
6.【强制】小数类型为decimal，禁止使用float和doubl。还好，我业务上强制不用小数存储。带小数的等比例转化为整数。
7.这个不好恒定。不过业务订单，可以使这个逻辑
8.【强制】varchar是可变长字符串，不预先分配存储空间，长度不要超过5000，如果存储长度大于此值，定义字段类型为text，独立出来一张表，用主键来对应，避免影响其它字段索引效率。
还好，一般数据量，也就在20-500不等。
9.【强制】表必备三字段：id, gmt_create, gmt_modified。
说明：其中id必为主键，类型为unsigned bigint、单表时自增、步长为1。gmt_create, gmt_modified的类型均为date_time类型，前者现在时表示主动创建，后者过去分词表示被动更新。
好想法，可以尝试用了。
二
1.【强制】业务上具有唯一特性的字段，即使是多个字段的组合，也必须建成唯一索引。
吓得我赶紧去看了我的角色名，果然，我当时做索引了。
2.【强制】超过三个表禁止join。
压根就不用jion，业务层解决，冗余索引解决。
3.还能这么干
7.【推荐】利用延迟关联或者子查询优化超多分页场景。
没用过，业务层可以解决一切。不过以后可以试试。
8.【推荐】SQL性能优化的目标：至少要达到range级别，要求是ref级别，如果可以是consts最好。说明：1）consts单表中最多只有一个匹配行（主键或者唯一索引），在优化阶段即可读取到数据。2）ref指的是使用普通的索引（normalindex）。3）range对索引进行范围检索。反例：explain表的结果，type=index，索引物理文件全扫描，速度非常慢，这个index级别比较range还低，与全表扫描是小巫见大巫
算起来，我用的最差也是双主键，要求指定前一个主键。
三
数据库操作还是用的少。
6.【强制】不得使用外键与级联，一切外键概念必须在应用层解决。
哈哈哈，这个太有用了，要不然迁移表就是噩梦。分布式处理也是噩梦。
7.【强制】禁止使用存储过程，存储过程难以调试和扩展，更没有移植性。
没用过，我还是喜欢应用层解决一切，数据层就安心的存数据就好了。
四
2.哈？略有尴尬，我得把mybatis生成器，再次修改了。
4.看了下，自动生成的xml，很稳。
8.我还要给每个字段定制不同的接口？还是每次都new一个类
六、工程结构
我最擅长的部分，工程架构。
二
1.一直没有好的定义方式。这看到标准了
但是基本延续了这个规则、com.公司名字.项目名字.分项名
7.这东西都是要定义的，严禁自己乱用。
8.好东西，7的执行就靠<dependencyManagement>
三
1.当年的原因找到了？
2.有被坑过。
633
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
