项目命名规范

“There are only two hard problems in Computer Science: cache invalidation and naming things.”
——Phil Karlton

命名是一项艰难而重要的任务，在Quora上也是经久不衰的好问题，按照如下的一些基本规则来进行命名，会帮助团队建设清晰而又精炼的项目结构：

• 基础命名法则：

  • 基础的命名方式参考 github 和 gitlab 的多数项目，适用小写+中划线命名法（lowercase and dashes pattern）。 eg: 项目命名为 project-name ，很显然你要同步的git地址也会是 http://the.git.address/group-name/project-name.git；

• 项目仓库（repository）通用命名法则：

  • 所有项目（repository）应根据自己提供的功能进行可以理解的清晰的描述，除非必要，一般使用名词单数。 eg：使用 purchase-rest-service 而不使用 rest-service 的描述；

  • 尽可能的避免使用大家不能理解的缩写、简写等。eg：不要使用xxx-pom-xxx之类的神秘词语进行描述；

  • 所有的业务产品线相关的项目在建立仓库时，需要带上相应产品线名称的前缀。eg: 商业平台的广告投放命名为 biz-demand-side-service；

• 微服务项目仓库（repository）的命名法则：

  • 关于微服务的项目命名应以-service 为后缀，来声明一个服务，不要以-server 或者 -platform或者 -api 这样宽泛的名词来进行描述。eg：内容管理的服务以 content-mangement-service 描述；

• 客户端项目仓库（repository）的命名法则：

  • 不同源的客户端统一以 -client 为后缀描述，由于平台的不同，可以通过叠加 -client-{platform} 来完善描述。 eg：Web端以 -client-web描述；，同样根据项目的颗粒度，更详尽的描述如 -client-wechat 、 -client-mobile 、 -client-ios-ipad也在允许范围之列。

• 工具脚本类项目仓库（repository）的命名法则：

  • 有些工具类的项目（repository）可能会根据其类型，在命名中通过 -plugin 、 -toolkit 或者 -script 后缀显示，这类项目以测试运维相关的居多。同样其用途或者适用场景可以在明明最后叠加 -{usage} 。 eg: jira打包工具 publish-toolkit-for-jira；

• 完整项目仓库（repository）的命名法则：

  • 有些项目因为其规模不大，其仓库包括前后端甚至一些脚本工具，适用与直接描述系统或者业务名称，这里有很多很好的案例，可以直接使用项目名称如 biz-intelligence 或者 oss-data-manager ；

• 其它注意事项或者案例（待完善）：

  • 一些案例的命名：-sample-{usage}/{platform}；
  • 一些开发工具包的命名：-sdk-{usage}/{platform}；