贡献代码

您可以报告bug，提交一个新的功能增强建议或者直接对以上内容提交改进补丁。

报告bug

本章节介绍如何提交一个bug。

报告一个新bug之前

  • 请确定这不是一个重复的bug。查看Issue Page列表，搜索您要提交的bug是否已经被报告过。
  • 确定在最新版本中该bug存在。我们将不会持续维护所有的发布版本，所有的修改仅根据当前版本。
  • 确认该bug是可以复现的，请尽量提供完整的重现步骤，并在github上提供可以复现问题的项目演示代码。

如何提交一个有质量的bug

请在Issue Page页面中提交bug。

  • 使用一个清晰并有描述性的标题来定义bug。
  • 详细的描述复现bug的步骤。包括您使用的SQL，配置情况，预计产生的结果，实际产生的结果。并附加详细的TRACE日志。
  • 在github提供用于可以复现问题的项目演示代码。
  • 如果程序抛出异常，请附加完整的堆栈日志。
  • 如有可能，请附上屏幕截图或动态的GIF图，这些图片能帮助演示整个问题的产生过程。
  • 如果涉及性能问题，请附加上CPU，内存或网络磁盘IO的Profile截图。
  • 说明适用的版本，只有release版本的bug才可以提交，并且应该是当前最新版本。
  • 说明适用的操作系统，及其版本。
  • 使用bug标签(Label)来标记这个issue。

以下是bug的Markdown模板，请按照该模板填写issue。

  1. [问题简单描述]
  3. **问题复现步骤:**
  5. 1. [第一步]
  6. 2. [第二步]
  7. 3. [其他步骤...]
  9. **期望的表现:**
  11. [在这里描述期望的表现]
  13. **观察到的表现:**
  15. [在这里描述观察到的表现]
  17. **屏幕截图和动态GIF图**
  19. ![复现步骤的屏幕截图和动态GIF图](图片的url)
  21. **Sharding-JDBC版本:** [输入Sharding-JDBC的版本]
  22. **操作系统及版本:** [输入操作系统及版本]

提交功能增强建议

本章节介绍如何提交一个功能增强建议。

提交一个功能增强建议之前

  • 请先检查详细功能列表。
  • 请确定这不是一个重复的功能增强建议。查看Issue Page列表，搜索您要提交的功能增强建议是否已经被提交过。

如何提交一个好的功能增强建议

请在Issue Page页面中提交功能增强建议。

  • 使用一个清晰并有描述性的标题来定义增强建议。
  • 详细描述增强功能的行为模式。
  • 解释说明为什么该功能是对大多数用户是有用的。新功能应该具有广泛的适用性。
  • 如有可能，可以列出其他数据库中间已经具备的类似功能。商用与开源软件均可。
  • 使用enhancement标签(Label)来标记这个issue。

以下是功能增强建议的Markdown模板，请按照该模板填写issue。

  1. [简单的建议描述]
  3. **建议的新功能行为**
  5. [描述新功能应表现的行为模式]
  7. **为什么这个新功能是对大多数用户有用的**
  9. [解释这个功能为什么对大多数用户是有用的]
  11. [列出其他的数据库中间件是否包含该功能，且如何实现的]

贡献补丁(patch)

本章节向贡献者介绍开发规范、环境、示例和文档。

开发理念

  • 用心写代码，提炼真正的非功能性需求。
  • 代码整洁干净到极致, 请参见《重构》和《代码整洁之道》。
  • 极简代码, 高度复用，无重复代码和配置。
  • 代码应在同一抽象层级。
  • 修改功能时多考虑影响面, 不可留下没修改完全的部分。
  • 只有一个需求时，不需扩展性。两个类似需求时, 再提炼扩展性。

开发行为规范

  • 提交之前先确定模块的测试套件，并使用测试覆盖率工具检查覆盖率不能低于master分支的覆盖率。
  • 使用Checkstyle检查代码, 违反验证规则的需要有特殊理由。模板位置在sharding-jdbc/src/resources/dd_checks.xml。
  • 执行mvn clean install可以测试和编译通过。
  • 及时删除无用代码。

编码规范

  • 写代码之前看一下系统已有的代码, 保持风格和使用方式一致。
  • 变量命名要有意义, 如果方法只有唯一的返回值, 使用result命名返回值. 循环中使用each命名循环变量, map中使用entry代替each。
  • 嵌套循环尽量提成方法。
  • 优先使用卫语句。
  • 配置文件使用驼峰命名, 文件名首字母小写。
  • 类和方法的访问权限控制为最小, 例如: 可以设为包私有的就不用public。
  • 方法所用到的私有方法应紧跟着该方法, 如果有多个私有方法, 书写私有方法应与私有方法在原方法的出现顺序相同。
  • 优先使用guava而非apache commons, 如：优先使用Strings而非StringUtils。
  • 优先使用lombok代替构造器, get, set, log方法。
  • 使用linux换行符。
  • 缩进（包含空行）和上一行保持一致。
  • 不应有无意义的空行。
  • 方法入参和返回值不允许为null，如有特殊情况需注释说明。
  • 需要注释解释的代码尽量提成小方法，用方法名称解释，注释应只包含javadoc和todo，fixme等。
  • 禁止使用static import。
  • 不需要公开的类放入internal包，包中类尽量包私有。
  • 日志一律使用英文。
  • 使用annotation获取spring的业务bean。
  • 如果模块中有公用的切入点，应在模块一级路径创建pointcut包。
  • 属性配置项需要添加到各个模块的常量枚举中。

单元测试规范

  • 测试代码和生产代码需遵守相同代码规范。
  • 如无特殊理由, 测试需全覆盖。
  • 准备环境的代码和测试代码分离。
  • 单数据断言, 应使用assertTrue, assertFalse, assertNull, assertNotNull。
  • 多数据断言, 应使用assertThat。
  • 精确断言, 尽量不使用not, containsString断言。
  • 调用业务方法的变量, 应命名为actualXXX, 期望值应命名为expectedXXX。
  • 只有junit assertXXX, hamcrest, mocktio相关可以使用static import。

编译代码

Sharding-JDBC的代码编译需要Maven，请保证IDE中正确配置了它。代码用到的所有依赖完全都可以从公网下载，请根据自身的网络情况选择合理的镜像。

代码使用了Lombok来生成类属性的访问方法，构造器等。故请以上从链接内容来获取适合您的IDE的解决方法。

文档生成

文档使用博客生成引擎HUGO，请根据文档安装环境。文档全部在sharding-jdbc/sharding-jdbc-doc/public目录中。

贡献方法

请按照规范贡献代码，示例和文档。

  • 所有的问题与新功能请使用Issue Page进行管理。
  • 任何人想要开发任何功能，请先回复该功能所关联的Issue，表明您当前正在这个Issue上工作。并在回复的时候为自己设置一个deadline，并添加的回复内容中。
  • 在核心贡献者找到一个导师(shepherd)，导师会在设计与功能实现上给予即时的反馈。
  • 您应该新建一个分支来开始您的工作，分支的名字为当前开发的dev/issueId。功能名称与导师讨论后确定。
  • 完成后，发送一个pull request到shardingjdbc当前开发的dev版本的分支，请不要提交PR到master分支中。接着导师做CodeReview，然后他会与您讨论一些细节（包括设计，实现，性能等）。当团队中所有人员对本次修改满意后，导师会将提交合并到当前开发版本的分支中。
  • 最后，恭喜您已经成为了Sharding-JDBC的官方贡献者！