这是我参与「第五届青训营」伴学笔记创作活动的第 10 天。
课堂笔记
一、本堂课重点内容：
- 开发流程
二、具体案例：
1. 为什么要有流程
1.1 团队规模和流程的关系
复杂项目没有流程会有什么问题:
- 需求阶段:每个人都有自己的想法，团队决策需要有一个过程
- 开发阶段:多人/多端协作开发，每个人有自己的安排，相互配合需要有一个流程
- 测试阶段:产物怎样交付，测试如何开展，BUG怎么修都需要流程
- 发布阶段:怎样确保发布过程平稳丝滑，版本和流量如何控制，需要有规范
- 运维阶段:线上问题如何应急响应，处理用户反馈和线上问题需要有流程
1.2 传统的瀑布模型
-
工作流程的直观表达
-
定义了标准的研发阶段
-
以流程为本，理想化模型
1.3 敏捷开发
- 以小团队快速迭代
- 团队成员之间的合作更加紧密
- 以人为本，和用户沟通
1.4 The Scaled Agile Framework (SAFe)简介
SAFe是一套管理框架
- 精益产品开发
- 敏捷软件开发
- 系统思考
现代的Scrum
- 敏捷教练Scrum Master·
- 产品负责人Product Owner
- 敏捷团队 Scrum Team
- 敏捷发布火车Agile Release Train
1.5 团队流程
2. 开发流程
2.1 需求阶段
- 站在用户的角度思考
- 收集用户反馈，快速迭代
2.2 开发阶段
传统虚拟机
- 在物理主机中虚拟出多个虚拟机，每个虚拟机拥有自己的操作系统
- 运维人员负责维护和交付虚拟机
- 每个虚拟机中都要安装相应的依赖环境
容器化
- 容器是在操作系统中虚拟出来的
- 通过cgroup, namespace和Union Mount等技术实现了容器之间的相互隔离，同时容器只有很低的开销
- 应用和其依赖作为一个整体，打包成镜像交付
单体架构
- 多个模块共同组成一个服务，服务体量较大。
- 模块之间直接调用，不需要RPC通信
- 服务整体扩缩容量
- 多人开发一个代码仓库，需要充分集成测试
微服务架构
- 各个功能在不同的服务中
- 不同模块需要进行RPC通信
- 不同模块可以独立扩缩容
- 每个服务的代码仓库仅由少部分人维护
代码规范
- 养成良好的注释习惯，超过三个月的代码，自己都会忘了当时在想什么
- 不要有魔法数字，魔法字符串
- 重复的逻辑抽象成公共的方法，不要copy代码
- 正确使用IDE的重构功能，防止修改错误乐
自测
- 单元测试
- 功能环境测试√测试数据构造
文档
- 大型改造需要有技术设计文档，方案评审
- 好的接口文档能更方便的和前端讲行沟通
2.3 测试阶段
功能环境
- 需要一个能模拟线上的环境进行开发和测试
- 环境和环境之间能够隔离，不影响其他功能的开发和测试
集成环境
- 不同人开发的功能合并在一起测试，相互之间的影响可能产生缺陷
- 迭代发布的所有功能合并在一起测试，确保发布的所有功能之间的影响不产生缺陷
回归环境
- 确保新的功能不对老的功能产生影响。回归测试一般会借助自动化测试脚本
2.4 发布阶段
-
蛮力发布
-
优点
- 简单
- 成本低
-
缺点
- 发布过程中服务会中断·
- 出了问题会影响全部用户
-
适用
- 测试环境部署
- 小公司或者非核心的业务服务
-
-
金丝雀发布
-
优点
- 相对简单
- 能够用少量用户验证新版本功能
-
缺点
- 发布过程中服务会中断
- 发现不了随用户量增大才会暴露的问题
-
适用
- 测试环境部署
- 小公司或者非核心的业务服务
-
-
滚动发布
-
优点
- 发布过程中用户体验不会中断
- 可以充分验证服务功能
-
缺点
- 流程较复杂，对发布系统有比较高的要求
- 发布速度较慢
- 新老版本不兼容的情况不能使用
-
适用
- 发布系统能力较强,可以平滑切换流量
- 发布自动化程度高，可以自动滚动
-
-
蓝绿发布
-
优点
- 发布速度快
- 流程相对简单
-
缺点
- 需要有一半机器承担所有流量的能力
- 出问题会影响全部用户
-
适用
- 服务器资源丰富
- 新老版本不能兼容的情况,需要一次性升级到新版
-
-
红黑发布
-
优点
- 发布速度快
- 流程相对简单
-
缺点
- 对机器数量仍然有要求，需要能扩容一倍
- 出问题会影响全部用户
-
适用
- 服务器资源丰富
- 新老版本不能兼容的情况，需要一次性升级到新版
-
2.5 运维阶段
飞机平飞阶段也有可能发生事故
- 用户量增加引起流量洪峰( 12306抢票)
- 数据库表的数据量增长导致查询速度变慢
- 内存/进程泄漏导致服务资源不足
- 光缆被挖断
三、课后个人总结
项目开发流程，软件工程的内容，开发流程，在大企业里还是比较好的实现了，小企业估计都是三五人开发，也不会有这种规则化的开发流程
