一、前言
在此将Java Web项目的实施规范做一个总结。
二、需求阶段
需求阶段主要包含需求分析和需求拆分，下面针对这两块做一个说明。
1.需求分析
需求分析是由PM撰写初稿，然后PM，DEV，FE，QA四方共同review之后定稿的文档。DEV在review需求文档的时候，一定要注意需求是否合理，评估需求实现难度，并对开发进行初步估时。对于不合理的需求要及时提出疑问并和PM方沟通是否有做的必要或者如何进行需求变更，对于实现难度较大的需求要和PM和FE沟通怎么做，因为开发都是迭代开发，那么就要确定这个需求是否本期一定要做，具体难点在哪里，如果实现的话是由FE实现还是DEV实现。在很多情况下开发资源都是极其紧缺的，如果确定这个需求要做的话，就要有大概的估时以确定本期需求实现的范围。
2.需求拆分
在大型项目中，需求拆分是很重要的一环，一般要按照功能模块进行拆分，但在在我们的项目中多人进行开发时会出现代码重复的问题，主要是service层代码的冲突。主要问题就是我们拆分的时候是分成前端展示系统模块和后台管理模块，然后再进行细分，因为类似查询的功能前后都需要去调用，所以会出现同样的service功能重复实现的问题。所以建议在功能模块拆分的时候可以依据service层的功能进行任务分配，这样可以避免一定范围上的代码重复问题。
三、准备阶段
准备阶段主要包含接口定义，数据库设计，开发环境搭建，技术选型这几方面的工作，在开发前把这几部分工作做好，并把技术难点提前处理可以避免开发过程中因为规范和难点问题造成的项目delay。
1.接口定义
DEV在定义接口时要及时和FE沟通，避免开发的时候频繁变动接口，接口的变动会带来很大的修改负担。接口一般使用json格式数据进行交互，要注意不是所有接口都一定要使用application/json格式的传输，单个参数可以约定成application/x-www-form-urlencoded，这样对于post请求后端就不需要必须使用实体类进行接收。接口设计要符合规范，统一命名并使用驼峰命名，一定要见名知意，下面给出一个例子。现在很多公司推广使用restful风格的接口，这个项目因为时间的原因依然沿用传统的命名规范。
2.数据库设计
数据库设计要满足Mysql开发规范，要统一风格并见名知意，对于类似用户名，时间这些经常需要查询的字段要建立索引，下面举一个例子。
3.开发环境搭建
3.1资源文件引入
开发环境搭建还是使用传统且较稳定的SSM框架构建Maven项目，也可以使用Spring Boot极大简化环境搭建。在项目的web.xml文件中需要引入spring-mvc.xml和applicationContext.xml。applicationContext.xml对应的是系统级别的配置，作用范围是系统上下文，所以它的初始化需要放到web.xml中的标签中，同时其他的类似定时任务的配置文件等等都是放在这个标签下进行初始化的。spring-mvc.xml对应的是 controller 级别的配置，作用范围是控制层上下文，说白了就是 servlet 级别的初始化，它不涉及到除了转发之外的任何实体，除了视图的解析方式、静态资源文件的存放位置、controller的初始化方式之外，其他的都不应该放在 servlet 配置文件中，应为它只负责请求的转发，返回结果的解析以及静态资源文件的解析，其他的对象的初始化，定时任务等都不应该放到这个配置文件下进行管理。之所以说那么多就是在进行配置的时候不要随意将spring-mvc.xml配置的内容放在applicationContext.xml，避免造成理解混乱，resource目录下的基本配置目录如下，mvc.xml对应controller级别配置，app.xml对应系统级别配置，同时包含mybatis.xml用于数据库事务相关配置，包含property.xml用于加载属性文件配置，其它相关的配置会放在对应的文件夹中，使得层级清晰。
3.2路径划分
代码的路径如何划分文件夹由很多种方式，我们采用如下的命名方式。annotation是自定义注解文件夹，aop是切面编程文件夹，constant是提取公共常量文件夹，controller是控制层文件夹，dao层是数据库操作层文件夹，dto是数据转换层文件夹用于复杂数据的层级转换，enums是枚举类文件夹，exception是自定义异常文件夹，interceptor是用于拦截器文件夹，model是model层文件夹，service是service层文件夹，transition是vo之间相互转化的文件夹，util是工具类文件夹，validator是自定义参数校验注解的文件夹，vo是接收和返回实体类的文件夹。
4.技术选型
技术选型包括开发中的常用技术选型，编码规范定义，重难点的提前调研以及公共类的编写。
4.1常用技术选型
常用技术选型就是把使用的一些框架开源组件罗列出来，保证开发组人员都按照统一的方案进行开发，相关技术选项如下。
4.2编码规范定义
编码规范定义是重中之重，可以参考阿里开发规范，并安装阿里规约扫描插件。因为项目之间是有差异的，所以一些细节可以写在对应项目规范下，部分标准如下。
4.3重难点的提前调研
在需求分析阶段是可以大概知道当前项目的重难点是那一块，所以最好提前做好调研工作，并进行对应的技术选型和demo编写，这样可以规避开发过程中项目delay的风险。
4.4公共类的编写
一般重复使用三次的功能模块就需要编写工具类，类似文件上传，二维码生成这些。对于统一异常处理，权限拦截，操作日志记录等也需要提前进行编码。mybatis关联数据库的mapper.xml和dao层可以通过mybatis-generator工具进行自动生成。
四、开发阶段
如果前面的工作准备的足够充分的话，开发过程也会特别的舒服，但是依然会遇到一些问题。主要集中在编码风格不统一，代码规范执行不足，以及push代码注释过于随意的问题。其实这几个问题总的来说依然是编码思想随意，所以最好遵从以下几个原则。
1.命名原则
所有的类和方法的命名要采用驼峰原则，要见名知意，不要因为单词过长进行简写，比如selectUserByName，如果使用selectByName会特别的奇怪。命名也需要做到统一，类似的方法和参数要有类似的命名，这样会使得编码风格趋于统一。
2.注释原则
所有的抽象方法（包括接口中的方法）必须要用javadoc注释，相关例子如下。service层的复杂逻辑也要有对应的注释，所有push到远程仓库的代码一定要说明当前改动的功能是什么。
3.性能原则
一般来说性能问题包含并发，缓存，幂等的问题。并发问题最常见的例子就是商品还剩余1个，如果多个用户同时点击购买可能会出现同时购买成功的情况，这个时候需要在数据库进行控制，可以建立联合唯一索引，也可以通过维护一个新的字段避免这个问题。缓存问题主要原因是因为同一时间多次操作会触发多次重复的数据库读，给DB造成很大压力，可以使用Guava cache的本地缓存，也可以使用redis缓存。幂等问题最经典的问题就是支付环境下由于网络延迟的原因用户可能会有多次支付请求，但是系统只会执行一次扣款操作，这个时候就需要在代码和数据库层级保证多次操作一次返回。
4.安全原则
一些类似用户电话和邮箱的名信息要进行加密处理，数据库中不能存储对应的明文信息，无关使用的接口也一定要注意是否暴露相关敏感信息。
5.数据出入原则
开发中采用入vo，出vo，复杂转换用dto的思想可以做到良好的层级隔离，避免入参出参混乱。一些常用的参数可以提取vo抽象类出来，减少vo冗余。
五、联调阶段
联调是指前后端的联调，大型公司很多项目会采用前后端分离，如果接口定义完备的话这一阶段一般不会出现太多问题，但是很多时候因为时间的原因使得接口定义不完整，造成很大的修改负担，这个时候就一定要和FE同学充分沟通，变动接口的时候一定要在群里周知。联调一般采用FE同学做到哪里就调试到哪里，所以一般情况下DEV同学的开发速度要快于FE同学。
六、测试阶段
测试包括DEV自测和QA测试。DEV自测有两种手段，一种使用postman等工具进行模拟测试，主要目的是为了保证接口可用性。另外一种是要写单元测试用例，因为时间的关系单测可能写的不够完备，但针对关键和复杂的逻辑一定要单测，尽可能的提高测试覆盖率。当DEV测试完成后可以提交QA测试，如果是新的项目QA测试的工作会特别大，需要做功能测试，压力测试，撰写checklist和对bug进行管理，这时DEV同学一定要认真配合QA同学的测试工作，良好的质量才是一个项目的最终价值体现。
七、验收阶段
验收阶段包括是PM对需求的验收和项目Leader对代码的review，如果前面的沟通工作做好的话PM验收也不会有太多问题，因为一切的开发都是按照需求文档来做的，所以如果出现实现的功能和需求文档不一致的情况，DEV同学就要认真反思并及时纠错了。Leader和其他同学在对代码review的时候，一般会提出一些问题，这个时候要及时回答并确认是否存在对应的问题，如果有问题就要及时记录，如果相关问题对本期需求影响不大可以放在下一期来优化，如果有明显的并发，性能，幂等的问题就要尽快修改，避免线上的bug出现。
原文链接：https://blog.csdn.net/cloud_xiaobai/article/details/79376763