规范

JHipster开发团队遵循一些编码规范。您可以将它们视为“最佳做法”或“指南”。它们是在项目本身而不是生成的代码上强制执行的:如果使用JHipster生成项目,则没有必要一定遵循它们!

这些规范由开发团队遵循,如果您提交Pull Request,则应遵循这些风格。

规范0:政策由开发团队投票决定

开发团队可以在邮件列表中讨论或修改每个规范。任何重大更改必须进行表决(如果您同意,则为+1;如果不同意,则为-1)。

规范1:JHipster使用的技术会尽可能使用其默认配置和最佳实践

例如,我们以“通常方式”使用JPA,Spring,Angular和React,而没有一些繁琐的配置选项以及它们通常的命名和编码约定。我们这样做是:

  • 通常,每种技术都有很好采用默认设置的理由
  • 如果我们不重新配置所有内容,则更容易了解JHipster的工作原理

仅当默认配置与JHipster使用的其他技术产生问题时,我们才可能更改默认配置。例如,要让Spring Security和Angular一起工作,我们必须更改Spring Security的默认配置。

规范2:仅在生成的代码中有足够的附加值或功能时时添加选项

生成项目时,JHipster有许多选项。仅当这些选项很复杂并且暗示配置或编码多个组件时,我们才添加它们。

添加选项仅是因为它节省了几行代码,但这并不是JHipster的好用法:

  • 手动编写这些行比学习新的JHipster选项要容易
  • 这只会使我们的生成器更加复杂,而不会增加任何价值

规范3:在服务器端和客户端对第三方库使用严格的版本

唯一的例外是对我们库的依赖,在这些库中,相对版本的效果更好。 库版本存在很多问题,会引起冲突。 这主要是JavaScript问题,因此请明确说明:我们在生成的package.json文件中使用固定的库版本。

规范4:我们在为相同目的而提供的不同选项中,提供尽可能一致的用户或开发人员体验

JHipster的一个重要方面是我们的用户和开发人员经验,以及您可以轻松地将一种技术交换到另一种技术(例如:客户端框架,身份验证,数据库等),因此,如果将开发人员配置/编码为尽可能相似。当它违反其他政策时,我们可以作为例外。

规范5:开发人员的经验可以优先于策略1、2、3和4。

这意味着我们需要确保开发人员的经验尽可能多的不受以下因素的影响:

  • 功能增加
  • 趋势驱动开发
  • 贡献者的便利
  • 技术热情

开发人员的经验是主观的,因此以下内容可以成为JHipster社区的粗略指南。这将是使用JHipster作为产品和平台的整体体验。包括:

  • JHipster CLI体验(易用性,直观性,速度等)
  • 生成的代码(质量,简单性,可读性,维护简便性,可升级性,熟悉性等)
  • 诸如JHipster在线,JDL studio之类的工具的UX
  • 文档(网站和生成的自述文件)

如果在执行本政策方面存在意见分歧,可以通过[邮件列表](https://groups.google.com/forum/?hl=zh-CN#!forum/jhipster-dev)来解决。