# 自研链技术管理流程改进经验
## 前期存在的问题
### 沟通协作效率低
- 频繁的多人在线会议
- 使用微信进行工作交流；发送和共享文档，代码，贴图等

### 任务追踪性差
- 任务要求不明确
- 工作无明确产出物，尤其是调研类，追查问题类
- 任务状态长期无更新

### 大量重复工作
- 开发构建环境，每个人自己搞一套。
- 测试脚本全是`hardcode`，不能通用。
- 同一个事情，第一个人没搞完或者做的有问题，第二个又得重头开始搞一遍，完全没法利用之前的工作。
- 有些疑难问题，反复出现；但是每次没有查到原因后都没有留下记录，下一次出现又重头查。

### 工程管理混乱
- 代码分支太多，且很多分支开发完后没有合并
- 没有统一的开发构建环境，每个人都有自己的搞法，且都是写死的。
- 产出物的质量缺乏标准（包括文档，代码等）。
- 缺乏有效的文档。

## 改进后的协作工作流
### 异步化
- 所有事项（需求，任务，讨论，问题）必须使用`Issue`跟踪，单个`Issue`只跟踪单个事项。
- 尽量用文字，代码引用描述清楚事项；@相关人员，相关人员在`Comment`进行讨论。讨论结果可以转换成新的需求，任务或者问题。尽量避免会议，如果必须会议也基于某个`Issue`上下文，会议过程中同样更新`Comment`。
- 代码提交同样使用异步流程，提交代码确认构建完成后，@相关人员进行代码检视。
- 所有人使用站内信通知，查看自己的待办事项，基本很少会被打断自己的工作，也避免去打断其他人。

### 标准化
- 晨会只需要对着自己的`Issue`来更新状态，尽量不发散，控制时间。有内容提交的`Issue`代码合并后，状态自动会更新。
- 所有任务对应`Issue`，除了讨论类的任务，明确其他任务的输出物都是文档或者代码，都提交到仓库。
- `Commit Message`使用最佳实践[Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/)
- 分支/发布管理使用较先进的[release-branches](https://docs.gitlab.com/ee/topics/gitlab_flow.html#release-branches-with-gitlab-flow)
- 默认的`Gitlab`[`PR/MR`](https://docs.gitlab.com/ee/topics/gitlab_flow.html#mergepull-requests-with-gitlab-flow)流程。
- 内部文档格式统一到`Markdown`（图表默认使用[Mermaid/D2](https://text-to-diagram.com/)，少数使用`draw.io`/`excalidraw`）。
- 因为考虑人员水平参吃不齐，每天统一时间做代码检视。召集人每天轮流，召集人主要负责发起会议和协助记录`Comment`。参考[最佳实践](https://docs.gitlab.com/ee/development/code_review.html#best-practices)。（统一时间并不一定最好，如果人员水平提高了，可以采用标准的异步`Review`）。
- 不启动链网络的测试都是用代码编写，需要启动链网络的测试都用`shell`进行包装。
- 默认的`Gitlab`[Release](https://docs.gitlab.com/ee/user/project/releases/)流程。

### 文档化
- 系统文档和代码统一代码仓库管理。使用文件服务器保存不适合上传到仓库的大文档。使用`wiki`维护项目统一的，但是和系统代码非紧密关联的信息。
- 新的需求都要求先进行设计再开发，设计文档着重功能设计，同时不能有明显的性能或者安全缺陷。文档随着代码改动同步更新（很难）。
- 清理合并有重叠的文档，同时维护一份。

### 自动化
- 重复的工作尽量使用脚本自动化。
- 构建，测试，文档生成，部署都使用脚本自动化。
- 清理合并有重叠的脚本，同时维护一份。

### 简单化
- 代码仓库数量从十几二十个减少到三至四个，只分为链和`SDK`，虽然代码结构上还是有很多模块和包，但是仓库其实没必要（参考很多大型项目，比如`Fabric`,`Kubernetes`）。单个仓库使用`Git`的`workflow`更简单方便。
- 之前有重复的脚本，文档都进行了清理，只维护一份。