Lesson8 从需求到上线全流程｜青训营笔记

五. 从需求到上线全流程

5.1 走进后端开发流程

• 为什么要有流程？

  个人开发者不需要流程，但超过一个人的团队需要协作，规模越大越容易出现问题

• 传统瀑布模型

  需求 -> 开发 -> 测试 -> 发布 -> 运维（较为低效）

• 敏捷开发

  以小团队快速迭代，以人为本和用户沟通

• Scrum

  在软件工程中，Scrum是以经验过程为依据，采用迭代、增量的方法来提高产品开发的可预见性并控制风险的理论，Scrum不是一种过程，也不是一项构建产品的技术，而是一个框架，在Scrum框架中可以应用各种过程和技术，Scrum的作用是让开发实践方法的相对功效显现出来以便随时改进。 Scrum是敏捷(Agile)开发的一种实践模式，敏捷开发强调拥抱需求变化，快速响应不断变化的需求，并尽可能快地提供可以工作的软件产品，敏捷最强调的是可以正常工作的软件产品，文档等不是非常的强调（并非不要文档，只是需要必要的文档），敏捷理论认为面对面的沟通交流远比文档更有效。 敏捷开发的Scrum模式是以价值驱动(Value-Driven)的开发模式，即认为用户的需求并不一定需要100%实现，最重要的是将对用户最有价值的功能实现并交付。

• Scrum Master

  是Scrum教练和团队带头人，确保团队合理的运作Scrum，并帮助团队扫除实施中的障碍。

• Product Owner

  产品负责人，确定产品的方向和愿景，定义产品发布的内容、优先级及交付时间，为产品投资回报率负责。

• 团队流程举例

  

5.2 开发流程拆解

5.2.1 需求阶段

不要浪费时间讨论不该存在的问题

程序员日常：砍产品经理的需求

MVP（最小化可行产品）思想：站在用户的角度思考，收集用户反馈，快速迭代，如下图所示：

时间安排：

5.2.2 开发阶段

如今进入了云原生开发时代，对比：

• 传统虚拟机

  在物理主机中虚拟多个虚拟机，每个虚拟机有自己的操作系统

  运维人员负责维护和交付虚拟机

  每个虚拟机要安装相应的依赖环境

• 容器化

  在操作系统中虚拟出来。

  通过cgroup，namespace和union mount等技术实现容器隔离，开销也很低

  应用和依赖作为一个整体，打包成镜像交付

• 单体架构

  多个模块共同组成一个服务，体量较大

  模块之间直接调用，不需要RPC通信

  服务整体扩缩容量

  多人开发一个代码仓库，需要充分集成调试

• 微服务架构

  各个功能在不同服务中

  不同模块使用RPC通信

  不同模块可以独立扩缩容

  每个服务的代码仓库仅由少部分人维护

在团队的分支策略决策上，详见Git的使用。

还有设计问题：

• 代码规范

  良好的注释习惯

  不要有魔法数字、魔法字符串

  重复的逻辑要抽象成公共的方法，不要copy代码

• 自测

  单元测试

  功能环境测试

  测试数据构造

• 文档

  要有技术设计文档，便于评审

  好的API文档，方便与前端沟通

5.2.3 测试阶段

越早发现BUG修复的成本越低，可以用一个测试金字塔表达：

修复时间与成本关系图：

环境：

• 功能环境

  需要一个能模拟线上的环境进行开发与测试

  环境之间要相互隔离，不影响其他功能开发与测试

• 集成环境

  不同人开发的功能要合并在一起测试，相互之间影响可能产生缺陷

  迭代发布的所有功能合并在一起测试，确保发布的功能之间影响不产生缺陷

• 回归环境

  确保新功能不会对老功能产生影响

  借助自动化测试脚本

5.2.4 发布阶段

• 发布负责人

  负责按照计划执行发布

  通知人员发布进展

  观察服务的发布状态，及时处理异常

• 变更服务相关的RD

  按照上线checklist检察服务日志、监控，响应上线过程中的告警

  对于自己负责的改动，在小流量或者是预览环境进行功能验证

  执行发布计划中的其他操作（线上配置、数据处理等）

• 值班同学

  关注发布过程中的监控和告警，如果是因为变更引起的要及时终止发布

• 发布模式

  蛮力发布：直接用新版本覆盖老板本，优点是成本低简单，缺点是发布过程中服务会中断，适用于非核心业务

  金丝雀发布：用少量用户验证新版本功能，缺点是发现不了随用户量增大才暴露的问题，适用于非核心业务

  滚动发布：每个实例都通过金丝雀方式发布，可以平滑切换流量（字节常用）

  蓝绿发布：将服务分为两组，用一半服务承接用户，另一半升级，最终两组全部升级，适用于服务器有限的情况，但这样负载也会更高

  红黑发布：与蓝绿发布类似，但发布时动态扩容出一组新的服务，要求服务器资源丰富

5.2.5 运维阶段

• 可能的问题：

  用户量增加引起流量洪峰

  数据库表中数据量增长导致查询速度变慢

  内存泄漏导致服务资源不足

  光缆被挖断

总结：从需求到上线全流程经过 需求 开发 测试 发布 运维 这五个阶段，每个阶段都有值得我们学习的细节，并思考为什么要这么做，最后的目的是为用户提供良好的服务。

5.3 流程怎样优化

• 如今：

  重视质量的团队，效率往往较低

  重视效率的团队，事故往往较多

  但随着技术的发展，质量和效率可以同时提高

• DevOps：

  代码管理、自动化测试、持续集成、持续交付产品交付

• 日常安排

  周一：产品功能演示和反思会

  周二：Grooming会议，需求规划会议，在backlog中确认需求

  周三：提交测试和发布申请，对其他人提交的工单进行Code Review

  周四：发布过程中如果出现异常，及时排查问题，如果是自己的代码有问题要回滚和修复

  周五：Planning会议，把需求的工作量进行评估，对时间进行排期