［项⽬规范］JAVAWEB项⽬实施规范
⼀：前⾔
在此将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极⼤简化环境搭建。在项⽬的l⽂件中需要引⼊l和l。l对应的是系统级别的配置，作⽤范围是系统上下⽂，所以它的初始化需要放到l中的<context-param>标签中，同时其他的类似定时任务的配置⽂件等等都是放在这个标签下
进⾏初始化的。l对应的是 controller 级别的配置，作⽤范围是控制层上下⽂，说⽩了就是 servlet 级别的初始化，它不涉及到除了转发之外的任何实体，除了视图的解析⽅式、静态资源⽂件的存放位置、controller的初始化⽅式之外，其他的都不应该放在 servlet 配置⽂件中，应为它只负责请求的转发，返回结果的解析以及静态资源⽂件的解析，其他的对象的初始化，定时任务等都不应该放到这个配置⽂件下进⾏管理。之所以说那么多就是在进⾏配置的时候不要随意将l配置的内容放在l，避免造成理解混乱，resource⽬录下的基本配置⽬录如下，l对应controller级别配置，l对应系统级别配置，同时包含l⽤于数据库事务相关配置，包含l⽤于加载属性⽂件配置，其它相关的配置会放在对应的⽂件夹中，使得层级清晰。
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关联数据库的l和dao层可以通过mybatis-generator⼯具进⾏⾃动⽣成。
四：开发阶段
如果前⾯的⼯作准备的⾜够充分的话，开发过程也会特别的舒服，但是依然会遇到⼀些问题。主要集中在编码风格不统⼀，代码规范执⾏不⾜，以及push代码注释过于随意的问题。其实这⼏个问题总的来说依然是编码思想随意，所以最好遵从以下⼏个原则。
1.命名原则
所有的类和⽅法的命名要采⽤驼峰原则，要见名知意，不要因为单词过长进⾏简写，⽐如selectUserByName，如果使⽤selectByName会特别的奇怪。命名也需要做到统⼀，类似的⽅法和参数要有类似的命名，这样会使得编码风格趋于统⼀。
2.注释原则
所有的抽象⽅法（包括接⼝中的⽅法）必须要⽤javadoc注释，相关例⼦如下。service层的复杂逻辑也要有对应的注释，所有push到远程仓库的代码⼀定要说明当前改动的功能是什么。
3.性能原则
⼀般来说性能问题包含并发，缓存，幂等的问题。并发问题最常见的例⼦就是商品还剩余1个，如果多个⽤户同时点击购买可能会出现同时购买成功的情况，这个时候需要在数据库进⾏控制，可以建⽴联合唯⼀索引，也可以通过维护⼀个新的字段避免这个问题。缓存问题主要原因是因为同⼀时间多次操作会触发多次重复的数据库读，给DB造成很⼤压⼒，可以使⽤Guava cache的本地缓存，也可以使⽤redis缓存。幂等问题最经典的问题就是⽀付环境下由于⽹络延迟的原因⽤户可能会有多次⽀付请求，但是系统只会执⾏⼀次扣款操作，这个时候就需要在代码和数据库层级保证多次操作⼀次返回。
java xml是什么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出现。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。