快速开始

开发注意事项

所有代码注释中 @author 值，不得采用中文或者英文的姓名，全部采用昵称。

所有代码注释中@date值，统一使用yyyy-mm-dd。

以下几点请务必和代码示例保持一致:

工具类编写/使用规范

• 工具类中一律不得出现main()方法，System.out.println()语句。

• 所有工具类中如需使用日志打印，一概不建议使用lombok提供的@Slf4j。

• 全部使用如下代码：

private static Logger log = LoggerFactory.getLogger(类名.class);

• 项目中使用到有如下几种，尽量使用其API中所提供的方法，如不满足项目需要，则参考现在工具类命名、注释标准编写。

1. Hutool
2. Guava
3. Apache Commons
4. Gson

Entity编写规范

• 所有以“id”作为主键的实体全部继承 BasePKEntity

• 不存在主键的实体统一继承 BaseEntity

• 表中有 CREATED_BY 和 UPDATED_BY 字段的统一写在表对应实体中，并且统一存储为： 当前操作用户的登录名

• 表中的 CREATED_TIME 和 UPDATED_TIME 字段在使用mapper自带的方法时均无需手动赋值，框架底层自动赋值，在使用手动编写的mapper时，请手动赋值。

Service/ServiceImpl编写规范

• 所有Service接口及其实现类注释全部采用 @Slf4j

• 使用系统自带代码生成工具所生成的代码请注意检查继承类是否正确

• 生成代码请手动添加代码注释，注释格式同以前代码注释保持一致

• 代码中使用到字符串比较请采用 StringUtils.equals(cs1, cs2)，不得采用 "".equals(anObject)方法

• 代码中使用到的特殊字符（标点符号，如：“”，/，_等等...），请使用 StringPool 类提供的常量，如不满足则采用字符串写法

• 依赖注入统一采用 @Autowired ，不得采用 @Resource ， @Component 等等

• 不得在同一个service调用多个mapper，多表操作请统一注入多个Service

Mapper/MapperXml编写规范

• 手动编写mapper请规范命名

• Mapper中出现多个参数必须使用 @Param

• xml中使用到如 java.lang.Integer 等等属性，全部采用简写 Integer，详细类型请参考mybatis-config.xml中所定义的类型

• xml中SQL格式请按照已存在格式编写

Controller编写规范

• 命名规范请保持和现有的一致，Mapping("")命名请保持和现有的一致

• 如果当前控制器需要获取用户信息请继承 BaseController ，若不需要则无需继承

• 继承 BaseController 的控制器形参中无需写 request 、response、 session，直接使用便可

• 控制器分为路由和数据两部分，请参考现有代码保证结构上一致

• Controller只做数据校验逻辑，业务逻辑严禁出现在该层，业务逻辑必须放在Service处理

View编写规范

• 模版命名请参考现有模版命名

• html编写请保证格式统一性，或者采用vscode等专业工具编写

• css命名请保持规范性，不要出现aaa、111、等奇葩的命名

• js方法命名同样请保持规范性，不要随意编写，同样也请保持代码格式

测试类编写规范

• 如需测试测试工具类，请在src/test/java下建立utils包，并编写对应的工具类测试类

• 测试用例编写也请建立对应类的包名，并在该包下编写

• 业务代码中请不要出现main方法等测试方法

Git提交规范

• 提交前请务必在本地测试代码的可用性和功能的完善性，并保证程序可以正常运行

• 提交时，请务必提交整个功能的完整代码

• 提交信息严格采用git提交规范编写，不得随意填写内容

• 提交信息分类严格按照git提交规范模版示例填写

代码注释规范

• 类、类属性、类方法的注释必须使用Javadoc 规范，使用/*内容/格式，不得使用
  // xxx 方式
  • 说明：在IDE 编辑窗口中，Javadoc 方式会提示相关注释，生成Javadoc 可以正确输出相应注释；在IDE
    中，工程调用方法时，不进入方法即可悬浮提示方法、参数、返回值的意义，提高阅读效率。
• 所有的类都必须添加创建者和创建日期
• 方法内部单行注释，在被注释语句上方另起一行，使用//注释。方法内部多行注释使用/* */注释，注意与代码对齐。
• 所有的枚举类型字段必须要有注释，说明每个数据项的用途。
• 代码修改的同时，注释也要进行相应的修改，尤其是参数、返回值、异常、核心逻辑等的修改。
  • 说明：代码与注释更新不同步，就像路网与导航软件更新不同步一样，如果导航软件严重滞后，就失去了导航的意义。
• 谨慎注释掉代码。在上方详细说明，而不是简单地注释掉。如果无用，则删除。
  • 说明：代码被注释掉有两种可能性：1）后续会恢复此段代码逻辑。2）永久不用。前者如果没有备注信息，难以知晓注释动机。后者建议直接删掉（代码仓库已然保存了历史代码）。
• 对于注释的要求：第一、能够准确反映设计思想和代码逻辑；第二、能够描述业务含义，使别的程序员能够迅速了解到代码背后的信息。完全没有注释的大段代码对于阅读者形同天书，注释是给自己看的，即使隔很长时间，也能清晰理解当时的思路；注释也是给继任者看的，使其能够快速接替自己的工作。
• 好的命名、代码结构是自解释的，注释力求精简准确、表达到位。避免出现注释的一个极端：过多过滥的注释，代码的逻辑一旦修改，修改注释是相当大的负担。
• 特殊注释标记，请注明标记人与标记时间。注意及时处理这些标记，通过标记扫描，经常清理此类标记。线上故障有时候就是来源于这些标记处的代码。
  • 待办事宜（TODO）:（标记人，标记时间，[预计处理时间]）
    表示需要实现，但目前还未实现的功能。这实际上是一个Javadoc 的标签，目前的Javadoc 还没
    有实现，但已经被广泛使用。只能应用于类，接口和方法（因为它是一个Javadoc 标签）。
  • 错误，不能工作（FIXME）:（标记人，标记时间，[预计处理时间]）
    在注释中用FIXME 标记某代码是错误的，而且不能工作，需要及时纠正的情况。
• 及时清理不再使用的代码段或配置信息。
  • 说明：对于垃圾代码或过时配置，坚决清理干净，避免程序过度臃肿，代码冗余。
  • 正例：对于暂时被注释掉，后续可能恢复使用的代码片断，在注释代码上方，统一规定使用三个斜杠(///)
    来说明注释掉代码的理由。

技术选型

• SpringBoot v2.2.1 war

• MyBatis-Plus v3.2.0

• SpringSecurity

• Smart-Doc

• Redis

• JWT

• Lombok

• Druid

• Hutool

• Guava

• Apache Commons

• Gson

• Quartz

• Elasticsearch (如需要)

• RabbitMq (如需要)

• MongoDb (如需要)

• Docker (如需要)

第三方选择

• 支付相关 IJPay-All
• 微信相关 mp-weixin
• 控制台 SQL日志打印插件 p6spy
• IP定位插件 ip2region
• 谷歌二维码生成 zxing
• 缩略图插件 thumbnailator
• Excel导入导出插件 ExcelKit
• 验证码生成插件 easy-captcha
• OOS 对象存储 qiniu-java-sdk