数据库规范、node风格、文件规范、版本规范、git规范

summary_2018/06 standard

1、日常工作

• 端午节放假当然还是小憩了一下，程序员也是需要休息滴，哈哈。。。
• 完成班学长学期总结发言稿
• 回顾一些规范，如:数据库、git（commit）规范、版本规范、node编码、文件命名规范

2、技术学习

• 一些规范可能是强制的，一些是公认的，也有一些规范是团队开发中的一些约定或采用某个规范，便于团队合作。因此，需以自己团队为基准

• 数据库规范

  • 当然这个规范不是标准的，只是一些经验+团队开发拟定的一些规范，这是我们团队拟定的
  • 规范：
    
    • 只能使用英文小写字母（a-z），数字（0-9），下划线（_），首字母必须使用（a_z）
    • 表示发生时间：均使用过去式加 at 进行命名，如 created_at，updated_at
    • 字段表示对象id的，以id进行命名，如：owner_id，parent_ids
    • 库名、表名以及表示对象集合的字段，若表示对象间关系，以 relations 进行命名
    • 库名、表名以及表示对象集合的字段，若表示某类事件记录，则以 log 进行命名（如user_action_log）
    • 字段名称不重复表名称，若重复，二级表示如course_name
    • 库名、表名以及表示对象集合的字段，若其含有某种集合类数据结构的特性，则使用内容对象的单数加上该数据结构的名称进行命名（如point_set）

• node编码规范

  • node文件的命名我们团队采用的是'-'连接，如get-mongondb
  • node区分大小写
  • 我们团队变量及函数命名采取驼峰式
  • 标准的一个规范是standard.js规范，webstorm可以开启，然后可以安装npm install eslint 来检测、修复代码
  • standard.js规范,具体的标准大家也可以看一下
  • ESlint
    
    • eslint(代码检查)、eslint --fix（代码修复） . 表示所有
    • 若安装jest,为让 ESLint 能正确识别测试文件，我们需要添加一些插件
      
      • 安装 eslint-plugin-jest：npm i -D eslint-plugin-jest
      • 打开 .eslintrc.yml 文件，修改内容如下：
      • extends:
      • - standard
      • - plugin:jest/recommended

• git规范

  • git 分支命名规范
    
    • master（主分支，永远是可用的稳定版本，不能直接在该分支上开发）
    • develop（开发主分支，所有新功能以这个分支来创建自己的开发分支，该分支只做只合并操作，不能直接在该分支上开发）
    • feature-xxx（功能开发分支，在develop上创建分支，以自己开发功能模块命名，功能测试正常后合并到develop分支，尽量只包含一个功能模块）
    • feature-xxx-fix(功能bug修复分支，feature分支合并之后发现bug，在develop上创建分支修复，之后合并回develop分支。PS:feature分支在申请合并之后，未合并之前还是可以提交代码的，所以feature在合并之前还可以在原分支上继续修复bug)
    • hotfix-xxx（紧急bug修改分支，在master分支上创建，修复完成后合并到 master）
  • git commit规范（- m）
    
    • Conventional Commits （约定式提交）,大家可以看一下
    • 标准介绍：
      
      • fix: 类型 为 fix 的提交表示在代码库中修复了一个 bug（这和语义化版本中的 PATCH 相对应）。
      • feat: 类型 为 feat 的提交表示在代码库中新增了一个功能（这和语义化版本中的 MINOR 相对应）。
      • BREAKING CHANGE: 在可选的正文或脚注的起始位置带有 BREAKING CHANGE: 的提交，表示引入了破坏性变更（这和语义化版本中的 MAJOR 相对应）。破坏性变更可以是任意 类型 提交的一部分。对于 fix:、feat: 和 chore:，乃至更多其它的 类型 而言，它都是有效的。
      • 其它在 fix: 和 feat: 之外的提交 类型 也都是支持的，例如 Angular 约定 中推荐使用 docs:、style:、refactor:、perf:、test:、chore:，但这些标签在约定式提交规范中并不是强制性的。
  • Tips（一些重要的点）：
    
    • 1、每个提交都必须使用类型字段前缀，这由一个形如 feat 或 fix 的名词组成，其后接冒号和空格。
      2、当一个提交为应用或类库实现了新特性时，必须使用 feat 类型。
      3、当一个提交为应用修复了 bug 时，必须使用 fix 类型。
      4、可选的作用域字段可以在类型后提供。作用域是描述代码库中某个部分的词组，封装在括号中，形如fix(parser): 等。
      5、描述字段必须紧接在类型或作用域前缀之后。描述指的是对代码变更的简短描述，形如 fix: array parsing issue when multiple spaces were contained in string.
      6、在简短描述之后，可以编写更长的提交正文，为代码变更提供额外的上下文信息。正文必须起始于描述字段结束的一个空行后。
      7、在正文结束的一个空行后，可以编写脚注（如果正文缺失，可以编写在描述之后）。脚注应当为代码变更包含额外的 issue 引用信息（例如它所修复的 issue，类似 Fixes #13 等）。
      8、破坏性变更必须在提交的正文或脚注加以展示。一个破坏性变更必须包含大写的文本 BREAKING CHANGE，紧跟冒号和空格。
      9、在 BREAKING CHANGE: 之后必须提供描述，以描述对 API 的变更。例如 BREAKING CHANGE: environment variables now take precedence over config files.
      10、脚注必须只包含 BREAKING CHANGE、外部链接、issue 引用和其它元数据信息。
      11、在提交说明中，可以使用 feat 和 fix 之外的类型

• 版本规范

  • 即开发的程序的版本变更标准,我们采用的标准是Semantic Versioning，大家有兴趣可以看一下

  • 主要内容和一些重要的地方：

    • 版本格式：主版本号.次版本号.修订号，版本号递增规则如下：
      主版本号：当你做了不兼容的 API 修改，
      次版本号：当你做了向下兼容的功能性新增，
      修订号：当你做了向下兼容的问题修正。

    • TIPS
      1、主版本号为零（0.y.z）的软件处于开发初始阶段，一切都可能随时被改变。这样的公共 API 不应该被视为稳定版。
      2、1.0.0 的版本号用于界定公共 API 的形成。这一版本之后所有的版本号更新都基于公共 API 及其修改内容。
      3、每当主版本号递增时，次版本号和修订号“必须 MUST ”归零。
      4、先行版本号“可以 MAY ”被标注在修订版之后，先加上一个连接号再加上一连串以句点分隔的标识符号来修饰。标识符号“必须 MUST ”由 ASCII 码的英数字和连接号 [0-9A-Za-z-] 组成，且“禁止 MUST NOT ”留白。数字型的标识符号“禁止 MUST NOT ”在前方补零。先行版的优先级低于相关联的标准版本。被标上先行版本号则表示这个版本并非稳定而且可能无法达到兼容的需求。范例：1.0.0-alpha、1.0.0-alpha.1、1.0.0-0.3.7、1.0.0-x.7.z.92。

    • FAQ：
      1、如何判断发布 1.0.0 版本的时机？
      当你的软件被用于正式环境，它应该已经达到了 1.0.0 版。如果你已经有个稳定的 API 被使用者依赖，也会是 1.0.0 版。如果你很担心向下兼容的问题，也应该算是 1.0.0 版了
      2、我该如何处理即将弃用的功能？
      弃用现存的功能是软件开发中的家常便饭，也通常是向前发展所必须的。当你弃用部份公共 API 时，你应该做两件事：（1）更新你的文件让使用者知道这个改变，（2）在适当的时机将弃用的功能透过新的次版本号发布。在新的主版本完全移除弃用功能前，至少要有一个次版本包含这个弃用信息，这样使用者才能平顺地转移到新版 API。

1、思考与总结

• 思考如何去回顾一个知识点、回顾+不断实践才能真正掌握好一个知识点
• 下次想写一篇关于如何学习的总结（开始学习->回顾->掌握）