开发中代码方向需要注意的事项（个人向）-只供参考

命名问题

每个人命名的方式都略有不同，最好遵从最简单最容易令人理解的方式命名

表命名

比如订单表用order，如果是大项目可能会带有前缀，例如：system_order
如果是通知表，我以前习惯性使用 noticification作为前缀，我建议简短成通知notice作为前缀
取名的时候尽量使用名称，不使用动词副词等。

字段命名

如果可以我建议参考大项目命名，或者参考专业术语
如果碰到有细节控的领导，你的命名会引起极大的不满，我建议如果出现几次这种问题，可以先咨询前人是怎么命名的，避免项目命名出现混乱，导致后期维护麻烦。

类命名

基本的命名，大家应该都知道，在java中使用驼峰，并且大写打头

方法命名

这里我主要说的是参与项目与别人合作开发，会碰到的问题
反正我大概就是天天被人喷出来的
如果公司有规范，我建议花个把小时把这些命名方式搞清楚
如果没有的话，我建议看看之前别人是怎么命名的尽量贴合之前命名习惯，不然会被喷，如果同级的人开发，只维护自己写的代码，当我没说

方法摆放顺序

我这里说的是合作开发项目，我是按照，查询，新增，修改，删除，摆放顺序

类的摆放以及各种依赖顺序

我自己是服务间依赖放在上面，插件等其他依赖依次摆放在下面，且服务间依赖最好按照项目顺序排列。

开发阶段

1、注释

方法注释这个最好写一下，至少标注下干嘛的，便于维护，如果是外包，瞎写就行了。
我个人习惯先写伪代码，写成注释，有时候写完会删了，我主要想说的是建议开发前把逻辑理清楚。

2、逻辑

最好把逻辑简单化，使用最简单的逻辑去实现，这步很难，可以先按自己思路去编写，写完后查看是否存在优化空间。
如果想到更好的优化方式或者更简单的方式实现，我建议是把之前的注释了，重新写一遍。
虽然这个过程会浪费一些时间，但是却比维护空间更高，比如你做完了，简单测试没啥问题，多人测试一下就报出问题，随着代码的叠加，这些问题非常难维护，这块深有体会，有时候甚至想全删除重写。
如果有时间的话，可以先把之前的注释了，重写试试。
接手别人的代码，建议先把每一块做什么的搞清楚再开始该，如果非常复杂我建议哪里报错删哪里，重构一遍代码，不然永远会有源源不绝的问题暴露。

3、最重要的一点

自测。
把测试步骤写出来，数据自己造，最好不要少于三条数据去测试。

一些日常记录

1、多对多才使用中间表
2、一对多使用关联，父子表
3、乐观锁解释：修改条件加上旧状态，满足旧状态才修改，以免造成重复修改
4、状态字段最好有流程依据的放在一起，如果存在没有直接相关的状态，新建一个字段存储
5、和定时任务相关，id最好由几个重要字段生成uuid，方便删除和修改
6、枚举和数据字典不要混为一谈，枚举是用来标记流程状态的，比如流程新增一个状态，会产生与代码相关的变化，一定要用枚举，数据字典适用于性别：男，女；国家：中国，韩国；年龄，一般不会涉及流程代码。
7、避免使用多层嵌套循环，可以了解一些算法问题，如果必要，可以尝试break满足条件后退出继续执行，也可将满足条件的打上标记后移除，在此之前需要使用深拷贝，以免之前的数据丢失。
8、事务一般使用@transaction,但是出现多服务间调用则会失去效果
解决方案：1、如果可以将这两个服务合并成一个服务就可以使用事务了，这个看情况使用
2、那就是每次请求前查看上次是否有失败的存在，如果存在，判断上一个逻辑是否成功，如果成功这一次直接写入，这个对事务需要存在一些关联性
3、那就是重启一个定时任务去监测是否存在失败的，则修改为正确的值，或者检测有失败的存在，把之前成功的回滚，这个对事务需要存在一些关联性
4、如果不存在任何关联性，那就手动try-catch捕获异常，手动回滚事务

结尾

以下个人开发总结经验：
pass：被喷经验
1、如果以上做不好，即使你觉得你开发能力很强，在别人眼里你依旧是个弱鸡。
2、如果你至少做好最后一步自测以及经常重写自己的代码，即便你懂的技术不多，在你领导或者同事面前，你至少也是优秀的。
3、如果不想被人喷，请把以上的都做好。
4、我被喷了无数次了，你懂的，被上司喷，容易自闭。