编码中需要注意的问题(持续更新)

昨晚加班将核三练习的作业提交给了师父，今早师父花了半小时给我讲了代码中存在的各种问题。今早是我认识师父以来感觉他最严肃的时候，可能是我的编码风格让有代码洁癖的他真的受不了了。师父说就算逻辑写的再漂亮而编码风格一团乱对看代码和之后维护的人而言简直是灾难，记下师父今早说的话，希望以后不会再成为别人的灾难。
1.在早期一定要养成严格的代码规范
编码规范比其他的都重要一些，规范的代码可更容易维护 ，更有助于代码审查 ，养成代码规范的习惯，有助于成长。规范的代码可以大大提高了程序的可读性，师父说，代码规范不代表高水平，但高水平的代码通常来说都是规范的，规范的代码更有利于帮助我理解，能够帮助我快速提升开发水平。代码不规范，即使写的再高明的算法，没准也被当作乱码处理掉。
2.注释规范
代码一定要有注释，对于方法，类，变量等等都要写注释，不能不写注释或者乱写注释，注释能帮助我们更好地理解代码的含义，增强可读性，写注释是对自己代码的负责。
3.代码复用问题
提交的代码中存在大量的冗余代码，很多实现相同功能的代码我写了多遍，仅仅只是因为传递的参数不一样，虽然实现了功能，逻辑也变得简单，但是在之后的维护中，如果需要修改某个地方，就可能有很多地方需要同时变动。比如：实现新增和修改我写了两个Service方法，但是实际上在新增和修改都是在进行保存操作，区别只是，若有ID不为空则进行修改操作，为空则进行新增操作，完全没有必要写成两个Service。再比如Mapper文件，我没有使用标签，许多select语句要查询的字段都是一样的，我就写了很多次，这样写虽然实现了功能，但是如果需求要求新增一个字段，那修改起来岂不是很麻烦？
4.判断尽量交给中间层而不是交给前台
在下图中保存单位信息时，前台JS判断“单位顺序号”是否为空，为空则新增，不为空则修改，而调用Service传递的参数一个是“业务流水号”，一个是“单位顺序号”，这种情况下可以让Service层判断处理。

5.数据库脚本问题
一定要先在eclispe里面写好数据库脚本再在数据库里面执行，而不是直接在数据库里面执行sql语句，eclipse里面规定脚本的编码是GBK编码，编码都是统一的，不可能要用脚本的时候从数据库里面导出脚本，开发并不是一个人在开发，大家都从数据库导出脚本，编码可能不一致，会使整理脚本的工作会变的非常复杂。
6.书写问题
我需要将开发规范熟记于心
1.我提交的Mapper文件的书写风格非常的乱，大写小写不统一，关键字，表名，字段书写风格不统一

2.“==”“||”等符号没有添加空格

3.代码缩进问题

7.不要用@Autowired注解，会出现“空”的情况
改成private CommDAO commDAO=(CommDAO)Util.getBean("commDAO")
在serviceA中调用serviceB，将dto对象传给serviceB中的方法，出现了空指针情况。所有以后不要用@Autowired注解方式