项目规范

[mayeths]

本项目的开发规范，请大家务必认真阅读并遵守。

总则

• 比较正规的讨论发 issue，可以记录讨论历史

• 如果讨论涉及具体的人，请@那个人。

• 每两周为一个迭代，召开一次迭代会议；每一周组织一次集中开发。

• 项目的具体规范、规则、公共事项（如前端开发公共事项）等，（除API外）均应该记录在一个issue中。

• 项目的API管理使用yapi平台。一切关于API的定义和规则以yapi中记载的内容为准。

• 如果一个issue是用于解决一个具体的问题/对具体事项的讨论，且具体的问题已被解决/讨论已经达成共识，则issue应当被关闭。

• 有一个 issue 记录项目需求，类似于 vscode: Iteration Plan for September 2019

• 有一个 issue 记录迭代计划： 第一轮迭代任务 #6

• 不明白的地方有两种解决方式：一是问一声大家怎么解决（DO NOT BE SHY），二是 Google（只要表达方式好，查的东西就绝对找得到）。

[mayeths]

迭代相关

• 每两周为一个迭代，召开一次迭代会议；每一周组织一次集中开发。
• 每一次迭代应单独开启一个迭代计划的issue，格式参见下文示例。
• issue中将详细列出每个人的迭代任务，使用可勾选列表的形式记录。如果某人完成了自己某一项任务，请将该任务自行打上勾。
• 每轮迭代后48小时内，由组长负责（可能的对代码适当修改）使得程序能够跑通成为release版本的动作
• 期间如遇到需要其他人配合解决的问题，应当发布issue

迭代任务范例:

第 N 次迭代

这是我们第 X 周到 第 X 周的迭代任务。

本次迭代我们会解决 XXX 需求，XXX 需求，XXX 需求，XXX 需求以及 XXX 需求。（我们也会解决 XXX）下面是详细信息。

迭代周期

• 第 X 周周 X：迭代开始
• 第 X 周周 X：迭代结束

计划项目

前端

• 活动列表 @Starrah
• 发起活动的填写表单 @Starrah
• 创建mpvue项目 @Starrah 创建前端mpvue示例项目 #3

后端

• ......

推迟项目

• 迭代过程中无法完成的上面项目拉到这里
• .......

---

请在本 issue 下方提出你的任何问题。

[mayeths]

github规范

• 开发阶段，每个人在自己的分支工作，并不断commit；进行一阶段的工作后，无需squash commits，直接发出pull request到develop分支。不要向master分支发出pull request！

• 除迭代末期产生迭代完成版本过程所需的pull request外，其他request需要有1~2个人进行 review 之后才能 merge 到 develop 里。这一过程可在迭代周期的全阶段进行。

• review代码的人需要在下方明确回复表示我已review，即使并没有什么问题要指出。

• 在一轮迭代彻底完成并merge所有的commit到develop，同时产品通过总体调试后，由组长发起一个pull request，把内容合并到master分支。

• 禁止任何人在任何情况下直接提交commit到master分支，必须发起pull request。

• 平时的commit 使用需要遵循 git commit 规范（以便之后可以用自动化工具生成 CHANGELOG（链接第五章））

• commit 到 master 之前可以 squash 一下 git 历史，也可不squash；因为merge PR的过程有一个squash and merge的选项。

• 除非提交的PR已被squash过(即提交版本仅有一个commit)，在执行merge PR时务必选择squash and merge！请务必注意，一旦操作错误修改十分麻烦。

参考工作流

• fork 本主仓库，git clone 自己的远程仓库到本地
• 一个迭代周期开始
  • 集中讨论，撰写第 N 次迭代任务的 issue 并置顶
  • 在 issue 中为每个人认领需求，在后面 @对应的人
  • 一个工作周期开始
    • 决定自己近日工作的某个需求，一次只工作一个需求。
    • 在本地建立新的分支，以需求缩写命名。
    • 在该分支上工作
    • （可能发生的）主仓库 master 有更改，git pull 到自己的本地 master 并 git merge 到正在工作的分支上
    • 工作结束， git merge 到自己的本地 master 上
    • git rebase 压缩 master 的 commit 历史，git commit --amend 按照 规范 修改 commit message
    • git push 本地 master 到自己的远程仓库 master 上
    • 在自己的远程仓库发起 pull request
    • 等待其他同伴进行：code review，merge 到主仓库，任一人在 issue 中标注该工作已完成
    • 删除该分支
  • 重复上一个步骤开始新的工作
• 重复上一个步骤开始新的迭代
• 项目验收

[Starrah]

项目具体规则、公共事项标准制定与修改规范

• 当开发中遇到一个问题，想要解决（或更好的解决）问题需要一些规范性的内容（如API接口、数据结构、枚举类型、工具函数等等）的建立，则遇到这个问题的人是有义务对此订立规范的人。

  • 举例而言，前端同学在开发活动列表页面时，意识到需要对活动的数据结构有所定义，和建立一个API接口用于获取活动列表。则他应该根据自己的需要，在yapi平台上定义相关接口和/或在github上发表/更新相关issue订立相关规范。
  • 同样的，当后端同学在开发中遇到了缺少某些接口等问题时，也应该根据自己的需要定义相关接口。
  • 如果一个规范的订立在相近的时间点内会被两人以上所需要，则不应互相推诿，第一个意识到这个问题的人就有义务订立此规范。

• 对于一件事情，如果在先前没有关于此的规则存在，则任何人都可以订立这一规则，然后非API相关的把它发在issue上、API相关的把它发在yapi上。

• 当一个已经订立的规则存在问题，需要进行修改时，修改者应视问题的严重程度采取通知措施：

• 可用的措施包括：

  • 直接修改，且额外通知（仅限于对现有规范进行增添式的修改，且修改的内容不直接对其他人产生干扰（例如，后端给一个API接口的返回内容增加一个字段）的情况）
  • 直接修改，之后通知他人：通知方式包括（重要程度等级递增）：微信、小型通知专用issue 小型消息通知专用楼 #16 、单开一个issue
  • 提出问题所在并询问对方的看法：方式包括（重要程度等级递增）：微信、小型通知专用issue 小型消息通知专用楼 #16 、单开一个issue、约线下讨论