这边我比较感兴趣的内容是后端的整体开发流程。下面是我做的笔记

首先，一个项目不是只缺少一个程序员。程序员是来干活的，但是干活之前需要做很多的准备。干活我觉得是最后的一步，而且这一步相对这个环节来说并不是那么重要的。因为你如果出现bug是比较正常的一件事情，这边还会有测试的阶段，你还可以做一些修改。更重要的是前期的沟通和交流。还有整个团队流程的规范。

当然，这个是针对于团队的。像个人开发者是不需要什么流程的，但是1个人能够做的事情毕竟是有限的，现在更多的是团队协作。

像一个复杂的项目。需要一个完整的流程是 需求阶段-->开发阶段-->测试阶段-->发布阶段-->运维阶段。

传统的模型：瀑布模型：在注重安全和稳定方面使用的流程。这边比起效率，更重要的是稳定和安全，像传统的银行或者支付宝业务。这边要求是：1年的bug不超过2个。这边工作都是定死的，所以开发效率比较底下。

后面互联网公司有一部分的业务就更加倾向于敏捷开发。敏捷开发更多的是一种思想：在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。就是重心把“流程”、“物品”，转移到“人”的身上。以人为主，人与人的交流和沟通为主。

通过一段时间的发展，衍变出来了一套规模化的框架（SAFe）

• 敏捷教练 -->队长：带领执行任务，安排节奏
• 产品负责人 -->产品经理
• 敏捷团队 -->干活的
• 敏捷发布火车 -->开发流程

eg:像字节两周为一个流程。每周二都会进行需求的讨论，要和客户进行面对面的沟通。第二周的周三要进行需求的评审、周四进行小范围的详情评审，周五进行安排，比如优先级啊、怎么安排流程啊、安排时间啊、这些内容。

细分开发流程

1、需求阶段

MVP思想

先给用户一个最小的、可以接受的内容，后面在最小的地方一点一点小心的叠加

四象限：个人感觉没什么卵用

2、开发阶段（云原生下的开发）

2.1传统的虚拟机和容器

这边我们在发展的过程中，之前使用的是传统的虚拟机，需要运维人员进行配各种各样的环境。确认环境和自己的需求是没有问题在进行开发，而且还需要申请，比较依赖系统的稳定性。

云原生的时代之下，所有的软件共享一个操作系统。所有的容器是相互隔离的，但是同时又不会造成很大的开销。我们确定了应用和依赖，可以打包进行一个镜像。

2.2 微服务（重点！）

前几年使用的架构是SOA架构（单体架构），把不同的模块做一个整体进行部署，这种服务的代码仓库很大。模块之间互相会有影响。缺点是可能自己改1行代码就会改挂了。优点是模块之间的调用不用通过网络。那么有些不需要扩容的内容也会随着进行扩容。

微服务：每个模块独立拆分出来，并且拆到不同的服务里面。按照单个的服务进行独立的扩容和缩容。减少了让很多人维护同一个代码的弊端，也可以更加精确的扩缩容。但是缺点是可能不同的服务之间要频繁的进行rpc通信。微服务越来越“微”，他网络通信开销会越来越大。

甚至开发环境也越来越云原生化。通过WEB IDE可以生成一个动态的带着运行池的容器，这里直接就有了所有的依赖。开箱即用。这边到了公司就可能不用前几天一直来配环境了（笑）。

2.3 团队的分支策略

2.4 代码规范、自测和文档

• 养成良好的注释习惯
• 不要有魔法数字、魔法字符串
• 重复的逻辑抽象成公用的方法
• 正确的使用IDE的重构功能，防止修改错误。

3、测试阶段

书籍推荐 -- 《Google软件测试之道》

为自己的代码负责。越早测试阶段成本就越低。

需要的环境

功能环境

集成环境

回归环境

4、发布阶段

在发布和回滚的时候，这边会遇见的bug是最多的！像很多互联网公司里面奇奇怪怪的要求，其实都是付出了血淋淋的教训换来的结果。

发布模式

1、蛮力发布

2、金丝雀发布

3、滚动发布

--字节一般使用的内容，因为用户体验是最好的。而且公司有强大的流量控制，

4、蓝绿发布

-- 对服务器的流量是要求的。这个我觉得是大部分企业会用到的。这边遇见兼容性的问题就会使用蓝绿发布，一般在低峰期进行发布。因为这段时间用户流量比较少，就算扩容一倍损耗也是比较少的。这也是为什么很多程序员需要加班的原因（悲）

5、红黑发布

5、运维阶段

可能会发生事故

• 用户量增长引起的流量洪峰
• 数据库表的数据量增长导致的查询速度变慢
• 内存/进程泄露导致服务器资源不足
• 光缆被挖断

需要做的事情：1 止损 2 周知 3 定位 4 修复