GO 后端开发流程

这是我参与「第五届青训营 」伴学笔记创作活动的第 12 天

2 有哪些流程

2.1 需求阶段

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

特斯拉进行生产线自动化的时候，有一个零件的安装自动化总是出问题，特斯拉的工程师为了优化这个自动化流程，投入了大量的资金和精力。后来马斯克问他们的技术人员，为什么需要这个零件，结果发现大家居然并不清楚。最后证明其实在电动车上，根本不需要这个零件。所以围绕着这个不应该存在的问题，进行了大量投入，造成了很多浪费。

MVP 思想

• 站在用户的角度思考
• 收集用户反馈，快速迭代

另外一个评估需求的方法，也是我们日常工作中安排自己任务的一个方法，就是四象限法：

当你很多任务的时候，可以按照这个坐标，把他们按照重要性和紧急程度分类。有些事情既重要又紧急，那么我们就应该先去做，不重要又不紧急的可以最后做而有些事情虽然重要但是不紧急他们的优先级应该比那些紧急但是不重要的事情高，因为如果我们不去处理，后面他们就会变得又重要又紧急。 这个理论的原则是先判断事情的重要性，再判断紧急程度。

2.2 开发阶段

2.2.1 云原生下的开发

传统虚拟机

• 在物理主机中虚拟出多个虚拟机，每个虚拟机拥有自己的操作系统
• 运维人员负责维护和交付虚拟机
• 每个虚拟机中都要安装相应的依赖环境

容器化

• 容器是在操作系统中虚拟出来的
• 通过cgroup， namespace和Union Mount等技术实现了容器之间的相互隔离，同时容器只有很低的开销
• 应用和其依赖作为一个整体，打包成镜像交付

单体架构

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

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

• 服务整体扩缩容量

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

微服务架构

• 各个功能在不同的服务中
• 不同模块需要进行RPC通信
• 不同模块可以独立扩缩容
• 每个服务的代码仓库仅由少部分人维护

开发环境逐渐云原生化

FaaS，PaaS等等技术，让开发逐渐从本地 IDE 向线上转变 从入职领到电脑搭建完一套完整的开发环境需要很久，通过 WEB IDE 等技术，环境未来将会开箱即用

2.2.2 团队的分支策略

有些团队会有一个专门的分支叫做release分支，大家都把代码合并到release分支，然后测试，发布，之后再把release分支合会master。有些团队会直接把开发的分支合入master， 然后再用某个master上的commit发布，之所以有各种各样的分支策略， 就是因为我们在后续的测试和发布阶段要按照对应的分支和commit进行交付。

2.2.3 代码规范、自测和文档

代码规范

• 养成良好的注释习惯，超过三个月的代码，自己都会忘了当时在想什么
• 不要有魔法数字，魔法字符串
• 重复的逻辑抽象成公共的方法，不要copy代码
• 正确使用IDE的重构功能，防止修改错误

自测

• 单元测试
• 功能环境测试
• 测试数据构造

文档

• 大型改造需要有技术设计文档，方案评审
• 好的接口文档能更方便的和前端进行沟通

2.3 测试阶段

你需要在写完每一段代码之 后立刻测试这段代码，当完成了更多的代码时，就要做更多的测试。测试不是独立隔离的活动，它本身就是开发过程的一部分，质量不等于测试，当你把开发过程和测试放到一起，就像在搅拌机里混合搅拌那样，直到不能区分彼此的时候，你就得到了质量。

2.3.1 测试流程

功能环境

• 需要一个能模拟线上的环境进行开发和测试
• 环境和环境之间能够隔离， 不影响其他功能的开发和测试

集成环境

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

回归环境

• 确保新的功能不对老的功能产生影响
• 回归测试一般会借助自动化测试脚本

2.4 发布阶段

2.4.1 发布过程中需要做的事情

发布负责人

• 负责按照计划执行发布
• 需要通知各个相关人员发布进展
• 观察各个服务的发布状态，及时处理异常

变更服务的相关RD

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

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

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

值班同学

• 发布过程中的监控和告警需要特别关注，如果有异常需要立刻判断是否由变更引起

• 如果有变更引起的告警或者用户反馈，需要及时中止发布

2.5 运维阶段

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