前言
作为一个优秀的项目经理或项目带头人，必须养成良好优秀的项目命名规则和习惯。
项目和文件命名规范化
一、项目名
全部小写，不加连字符、下划线，比如erp，workdesk，jobserver等
二、java相关命名
1. 类命名
每音节单词前的第一个字母大写，比如FieldInfo、Expression等
2. 普通变量(包括spring里的变量引用命名)
第一个单词前小写，以后每个单词第一个字母大写，password,primaryFlag
3. 静态变量
4. 包package命名
5. 补充
- 类名、变量名是名字组合，多名词顺序和中文顺序一样，比如ScriptEngine
- 属性也可以是形容词+名词
- 常量可使用上述规则，如果为了体现多个常量是一组的概念，也可以被修饰前置，比如：VAR_START，VAR_END.
- 方法是动词+名字或者只有动词
三、项目其他文件
1. 属性文件.properties定义变量命名
object.a_b_c格式，全部小写，其中object是宿主，a_b_c多个单词下划线分开。例：
hibernate.cache.use_second_level_cache，
hibernate.cache.provider_class，
hibernate.cache.provider_configuration_file_resource_path
以下划线隔开：errors_zh_CN.properties，hibernate_test.properties
2. xml文件命名
全部小写，-符号是其xml的用途说明，类似applicationContext属习惯命名。比如springmvc-servlet.xml、workdesk-manager.xml、workdesk-servlet.xml、applicationContext-basic.xml等。
xml里的内容多个字符间以-隔开，比如param-name，filter-mapping等
3. 普通文件命名(jsp,js,img等)
和java普通变量规范相同
四、数据库命名：
表、字段命名全部大写，多个单词以_隔开
五、所有命名规则
1)、名称只能由字母、数字、下划线、$符号组成
2)、不能以数字开头
3)、名称不能使用Java中的关键字。
4)、坚决不允许出现中文及拼音命名。
版本命名规范
1. 版本号的格式为 X.Y.Z(又称 Major.Minor.Patch)，递增的规则为：
- X 表示主版本号，当 API 的兼容性变化时，X 需递增。
- Y 表示次版本号，当增加功能时(不影响 API 的兼容性)，Y 需递增。
- Z 表示修订号，当做 Bug 修复时(不影响 API 的兼容性)，Z 需递增。
详细的规则如下：
- X, Y, Z 必须为非负整数，且不得包含前导零，必须按数值递增，如 1.9.0 -> 1.10.0 -> 1.11.0
- 0.Y.Z 的版本号表明软件处于初始开发阶段，意味着 API 可能不稳定；1.0.0 表明版本已有稳定的 API。
- 当 API 的兼容性变化时，X 必须递增，Y 和 Z 同时设置为 0；当新增功能(不影响 API 的兼容性)或者 API 被标记为 Deprecated 时，Y 必须递增，同时 Z 设置为 0；当进行 bug fix 时，Z 必须递增。
- 先行版本号(Pre-release)意味该版本不稳定，可能存在兼容性问题，其格式为：X.Y.Z.[a-c][正整数]，如 1.0.0.a1，1.0.0.b99，1.0.0.c1000。
- 开发版本号常用于 CI-CD，格式为 X.Y.Z.dev[正整数]，如 1.0.1.dev4。
- 版本号的排序规则为依次比较主版本号、次版本号和修订号的数值，如 1.0.0 < 1.0.1 < 1.1.1 < 2.0.0；对于先行版本号和开发版本号，有：1.0.0.a100 < 1.0.0，2.1.0.dev3 < 2.1.0；当存在字母时，以 ASCII 的排序来比较，如 1.0.0.a1 < 1.0.0.b1。
- 注意：版本一经发布，不得修改其内容，任何修改必须在新版本发布！
一些修饰的词
- alpha：内部版本
- beta：测试版
- demo：演示版
- enhance：增强版
- free：自由版
- full version：完整版，即正式版
- lts：长期维护版本
- release：发行版
- rc：即将作为正式版发布
- standard：标准版
- ultimate：旗舰版
- upgrade：升级版
版本号的命名和更新问题，是开发者的责任感和前瞻性的问题。
2. 开发流程
1. 项目立项时
2. 开发阶段时
此时系统尚不稳定，随时可能增减或者修正API。
版本格式：0.次版本号.修订号，版本号递增规则如下：
主版本号：0表示正在开发阶段；
次版本号：增加新的功能时增加；
修订号：只要有改动就增加。
3. 开发完成后，发布API，或进入二方库时
此时系统已经基本稳定，可以对外公布使用，意味着API不再会被随意修改。
版本格式：1.0.0
4. 后续的维护升级时
没有特殊需求不会修改API，尤其是对API进行不兼容的升级，或弃用时要特别谨慎。如果需要弃用API，要提前在一个或几个版本中加入弃用标示或注解，并在文档中，建议用户更换为其他可替换的API，然后在下个主版本号升级时，再真正丢掉弃用的API。
版本格式：主版本号.次版本号.修订号，版本号递增规则如下：
主版本号：全盘重构时增加；重大功能或方向改变时增加；大范围不兼容之前的接口时增加；
次版本号：增加新的业务功能时增加；
修订号：增加新的接口时增加；在接口不变的情况下，增加接口的非必填属性时增加；增强和扩展接口功能时增加。
新增接口：如果该新增的接口只是对现有的业务线进行扩展则增加修订号；如果是为了增加新的业务线则增加次版本号。
5. 先行版本号和开发版本号
先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面，作为延伸。
- 先行版本号(Pre-release)：意味该版本不稳定，可能存在兼容性问题。 其格式为：X.Y.Z.[a-c][正整数]，如 1.0.0.a1，1.0.0.b99，1.0.0.c1000。
- 开发版本号：常用于 CI-CD（持续集成和持续交付）。 格式为 X.Y.Z-dev[正整数]，如 1.0.1-dev4。
- 版本号的排序规则为依次比较主版本号、次版本号和修订号的数值，如 1.0.0 < 1.0.1 < 1.1.1 < 2.0.0；对于先行版本号和开发版本号，有：1.0.0.a100 < 1.0.0，2.1.0-dev3 < 2.1.0；当存在字母时，以 ASCII 的排序来比较，如 1.0.0.a1 < 1.0.0.b1。
參考
若有收获，就点个赞吧
0 人点赞
