后端开发流程
为什么需要流程？
产品要上线需要考虑很多问题：
- 决策筛选出合理的需求
- 迭代任务的分配，协作开发的配合
- 产品交付，测试工作的开展
- 发布与版本控制
- 运维处理
软件工程课介绍的瀑布模型就是定义了一整个流程：
需求 -> 设计 -> 开发 -> 测试 -> 维护
但瀑布模型不够灵活，因此出现了敏捷。当然敏捷是啥我不敢说我懂，毕竟也没怎么接触。
课上讲述的对于流程的改进：在小团队中以小目标进行多次瀑布的迭代，可以使得整个流程更加灵活。
具体流程
需求
需求应当是最为重要的阶段，因为产品最终需要交付使用。这一阶段需要注意的有：
- 需求筛选：MVP 最小可行化产品思想
- 需求分类：按重要与紧急二维分类。
开发
- 云原生下的开发： 虚拟机、单机 -> 容器化、微服务
- 分支策略：这里贴一个阮一峰的git分支策略中文版
- 代码规范、测试与文档
测试
越早发现错误解决成本越低。
测试需要考虑什么：
- 新功能在模拟环境中正确
- 迭代发布的不同功能互不影响
- 新功能不影响旧功能
发布
80%的事故都发生在起飞与降落。
介绍了几种发布模式：
- 蛮力发布：直接覆盖
- 金丝雀发布：改变一小部分试水
- 滚动发布：慢慢扩大金丝雀的范围
- 蓝绿发布：分成两半AB，A承担所有流量，B更新；B承担所有流量，A更新
- 红黑发布：富裕版蓝绿更新，新开一倍服务器来承受
DevOps
只能上经典配图：
后端开发的一周
我也好想去后端开发。
Git 使用
Git基本命令
.git/config文件中：
git config- 用户配置
- instead of
- alias
- credential.helper
git remote- -v 查看
- add
- remove
.git/objects文件夹中：
commit/tree/blob/tag。
commit的ID对应的文件中存储着Tree的ID
tree的ID对应的文件中有目录树信息，也就是blob的ID
blob文件中存着文件的内容
.git/refs文件夹中：
heads对应着分支 tags对应着标签 实际上都是存储着对应的commitID
修改历史版本
commit --amend可以修改commit信息，相当于覆盖。rebasefilter -branch
但是修改commit信息之后可能会导致dangling objects，可以通过
git fsck --lost-found来查看，通过git gc来清理和压缩object，
git reflog记录操作日志防止误操作后丢失。
Git研发流程
上面贴了一篇git flow，与之对应的还有GitHub flow和gitlab flow用作分支管理工作流。
Github flow只有一个主分支，基于PR进行合入操作。
Gitlab flow要求upstream first，只有上游分支采纳才能进入下游分支。暂时先贴一篇教程记一下。
