前言
本文总结开发中，不常注意但又重要的开发规范，开发流程规范、已知缺陷、心得。推荐阅读《阿里巴巴开发规范》、《架构整洁之道》、《凤凰架构》、《clean code》等书籍，另外建议Idea安装alibaba java coding guidelines插件，每次提交代码在tools-阿里编码规约-编码规约扫描，将扫描的问题全部解决，长久下去，代码水平将会得到提升。
1、开发流程
- 根据需求，编写这次需求迭代的设计文档，设计文档包括：需求背景、流程图（特别复杂的业务建议画时序图）、表结构设计、难点和痛点（每个难点自己先设计一套方案）；
- 技术评审，可以通过短会，头脑风暴，或者只和leader过一下第一步的设计文档，确保设计上没有缺陷，最重要的是，确定所有难点的解决方案合理；
- codeing and unit test，写完代码，第一时间使用alibaba java coding guidelines插件扫描（这一步很重要，长期坚持，可以提高自己的编码水平），解决所有问题后，再commit代码;
- 代码review，提高代码的健壮性，核心功能的代码必须小组内review，这样可以建立AB角，提升团队掌握核心业务的代码，非核心，至少保证有一个B角review代码（往往自己代码中很低级的bug，别人一眼就看出来了，自己死活看不出来），修改review后提出的所有问题；
- 提测，这一步一定是在代码review之后，否则会导致，回测测试，提高测试成本；
- 测试，这里指的是集成测试和压力测试等；
- 上线，产品验证。
注意：如果是后台管理系统，或者hot fix，或者紧急需求，第一步和第二步可以简化。
2、开发规范
- git commit push一定要加说明，不能随意写；
- 获取当前毫秒数：System.currentTimeMillis(); 而不是new Date().getTime();
- 循环体内，字符串的联接方式，使用StringBuilder的append方法进行扩展；
- 所有的包装类对象之间值的比较，全部使用equals方法比较；
- 避免用Apache Beanutils进行属性的copy；
- 不能使用过时的类或方法；
- 在if/else/for/while/do语句中必须使用大括号，即使只有一行代码，避免使用下面的形式：if (condition) statements;
- 在一个switch块内，每个case要么通过break/return等来终止，要么注释说明程序将继续执行到哪一个case为止；在一个switch块内，都必须包含一个default语句并且放在最后，即使它什么代码也没有；
- 属性命名禁止使用is开头的命名方式，如isDeleted、isSuccess，否则在fastjson序列化和反序列化时出现不必要的错误；
- 一个方法只能干一件事，学会抽方法，增加代码可读性和扩展性；
- catch中不建议使用e.printStackTrace()；
- 高并发场景下，禁止使用System.out.println()，out.println()方法内部使用synchronized；
- 一行代码不超过一横屏；
- 所有实现Serializable接口的对象 要求显式地声明一个 serialVersionUID，以避免频繁的序列化异常 ，可参考：blog.csdn.net/chang_ge/ar…；
- 反复多次使用的方法，要考虑定义成抽象模版方法；
- 学会使用抽象工厂设计模式，利用接口，抽象类，实现类，使自己的代码逻辑分层，易读易懂易维护；
3、已知缺陷
- Map/Set的key为自定义对象时，必须重写hashCode和equals；
- Object的equals方法容易抛空指针异常，应使用常量或确定有值的对象来调用equals；
- POJO类中的任何布尔类型的变量，都不要加is，否则部分框架解析会引起序列化错误；
- 不要在foreach循环里进行元素的remove/add操作，remove元素请使用Iterator方式；
- 在subList场景中，高度注意对原列表的修改，会导致子列表的遍历、增加、删除均产生ConcurrentModificationException异常；
- 使用工具类Arrays.asList()把数组转换成集合时，不能使用其修改集合相关的方法，它的add/remove/clear方法会抛出UnsupportedOperationException异常；
4、心得
在平时的开发工作中，就算自己所在的业务线，不是高并发场景，也要用高并发这把尺子，去衡量自己开发过程中的不足，因为高并发代表了高标准、高水平，就像有的人不打游戏，却买游戏本办公，因为大型单机游戏都能运行起来的笔记本，性能肯定好，而且，这样做的好处是：
- 可以提高你的编码水平，不要等那天真的来高并发需求了，自己不会，没弄过，匆忙上手，不了解底层，就容易产生bug；
- 用高并发的标准开发低并发场景，可以极大减少故障率，因为你考虑的更加全面，最怕业务线并发稍微高一点，系统就炸了，因为业务是不断增长的，讲不好那个业务会长期使用，增长起来，所以一开始做好，后面自己才有余量去做更深层次的优化；
当然一些业务几十年之内都不会有特别大的并发，也不用过分的追求优化架构，因为这样开发成本会比较高，但一些常规的高并发解决方案，一定要学会使用，并运用到实际开发中，掌握原理，比如：分布式锁、数据库锁、JUC、MQ等；如果你之前在这方面经验欠缺，也不要担心，每种技术使用三遍，基本就能掌握，关键是迈出的第一步，养成习惯，后面就能熟练的写出，高水平的代码。
