走进后端开发流程
整个课程会带大家先从理论出发，思考为什么有流程
大家以后工作的团队可能不一样，那么不同的团队也会有不同的流程，这背后的逻辑是什么
然后会带大家按照走一遍从需求到上线的全流程，告诉大家在流程的每个阶段，究竟要做什么
最后会给大家介绍一下我们实践当中怎样让流程更加有效率，让程序员的生活更美好，而不是把人变成拧螺丝的机器
1.1 团队规模和流程的关系
当我们要开发的产品复杂了之后，究竟会遇到哪些问题？
按照阶段来看： 比如我们的想法可能不同，每个人都有自己的想法 甚至有一些还是馊主意，怎么去把这些各种各样的意见统一，这样团队就需要一个决策的过程 多人或者多端配合开发的时候，每个人都有自己的安排，你的代码跟我的代码怎么合到一起，什么时候一起联调？都需要有流程 再到后面开发出的产物交付测试，遇到了BUG怎么修，怎么让测试的功能之间不相互影响 最终好不容易我们的产品要上线了，上线要通过哪些方式，上线之后的运维又要做哪些事情 这些都需要有一个规范和流程
1.2 传统的瀑布模型
按照我们最传统的也是最直觉的模型 把整个软件开发按照各个阶段排成一条线 前一个阶段完成之后进行下一个阶段
1.3 敏捷开发
后来互联网公司的流程逐渐倾向于敏捷
其实这里的敏捷指的更多的是一种思想 追根溯源的话 2001年的时候，有一帮程序员，在美国犹他州的一个滑雪圣地举行的一次聚会，在聚会上他们定了这个宣言 就是因为当时的软件开发流程太过于重视流程本身，没法快速灵活的适应市场变化
1.4 The Scaled Agile Framework (SAFe) 简介
在实践当中，现在敏捷已经发展出了一套规模化的管理的框架
也就说所谓的SAFe 这套框架是为企业中实施敏捷开发提供一套方法论 如果说敏捷开发是一个团队内部的协作方式，那么SAFe就是在企业中，多个敏捷团队之间怎样配合 如果大家到了目前一些比较大的厂工作，应该实际接触的就是这套模型 比较理论的东西我们不去深入讨论：比如精益产品开发，敏捷软件开发，系统思考等等，这里专门开一门课都未必能讲完
如果一个scrum就是一个战术小队 敏捷教练就好比是小队的队长，产品负责人是负责联络指挥部和发布任务的人， 其他团队成员就是特种兵 大家也不是按照一个方阵去前进，而是用更敏捷的方式去前进，也就说敏捷发布火车
1.5 流程例子
我们每个迭代有两周，同时我们有两个scrum，
因此站会是两个scrum交替进行 带大家过一下整个流程 从时间表上可以看到，我们会在迭代的第二周周二开grooming会议，周五开planning会议 至于评审和反思会议，一般要是需要的时候才会开。 回到我们开头的例子，如果要开发一个类似抖音一样的复杂产品，那么需要的不是一个程序员，而是像这个的几十上百个这样的团队，通力合作 背后也不仅仅是程序员，还有各种各样的团队成员共同努力，才能最终把我们的想法变成实际的产品
开发流程拆解与介绍
2.1需求阶段
说到需求阶段，马斯克在接受一个采访的时候讲过一个故事 他们在做特斯拉生产线的自动化的时候，有一个零件的安装自动化总是出问题 特斯拉的工程师为了优化这个自动化流程，投入了大量的资金和精力 后来马斯克问他们的技术人员，为什么需要这个零件， 结果发现大家居然并不清楚 最后证明其实在电动车上，根本不需要这个零件 所以围绕着这个不应该存在的问题，进行了大量投入，造成了很多浪费
所以，这个故事就告诉我们一个道理，不要浪费时间讨论不应该存在的问题
还记得我们刚才提到grooming会议，就是在那个会议上，大家会讨论什么需求该做，什么不该做 这个会议 现在我们的几个产品经理现在都不用我们动手，轮到自己的时候自己先砍几刀，说：这几个可以不做，但是其他的必须做 不过大家也都不跟他们客气，该砍的还是砍 不过玩笑归玩笑，我们作为后端开发，除了砍需求，还要学会站在用户的角度评估需求
2.1.2 需求评估 MVP&四象限
需求究竟应该怎么评估 这里教大家一个MVP的思维方式
如果我们要给用户造一辆车，我们不应该第一天给他一个轮子，第二天给两个轮子，第三天给他一个底盘，第四天才让他开上车 我们应该先给用户一个简单能用的产品，比如一个滑板车，一个自行车，根据用户的反馈我们再逐步把车的功能升级，最终变成用户想要的产品
另外一个评估需求的方法，也是我们日常工作中安排自己任务的一个方法，就是四象限法：
当你很多任务的时候，可以按照这个坐标，把他们按照重要性和紧急程度分类
有些事情既重要又紧急，那么我们就应该先去做，不重要又不紧急的可以最后做 而有些事情虽然重要但是不紧急他们的优先级应该比那些紧急但是不重要的事情高，因为如果我们不去处理，后面他们就会变得又重要又紧急 这个理论的原则是先判断事情的重要性，再判断紧急程度 一个高效的占比，应该是大多数时间在处理重要但不紧急的事情，因为一旦一件事情变成了紧急，那我们就容易犯错误，因此如果每天大部分时间都在处理重要且紧急的事情，那么其实是不健康的
2.2 开发阶段
首先大家正在一个时代的变革中，因为云原生的发展，现在的后端开发工作跟几年前已经有了很大的区别 什么是云原生？ 作为后端开发同学，大家应该把Kubernetes和容器技术作为一个基础知识， 如果过去在虚拟主机的开发是用剑决斗 那在云原生技术爆发的当下，就是能在决斗中用枪了 所以就像这张图一样，“大人，时代变了” 当然我们这门课不会太着重去介绍云原生和相关的技术细节，后续会有专门介绍服务架构和微服务的课程 我们这里重点介绍一下这种变化对我们日常的开发会产生什么影响
2.2.2 云原生开发
云原生下的开发，一个最大的区别就是部署的形式不同
传统虚拟机上的服务开发，是在物理机或者是更底层上虚拟出多个虚拟主机， 然后在每个虚拟主机中安装软件和依赖 虚拟机需要有专门的运维人员维护 本地开发的时候也大多是直接在电脑上运行程序
而开发云原生的后端程序，容器是从操作系统中虚拟出来的，所有容器共享宿主机的系统， 通过cgroup，namespace和union mount实现了容器之间的隔离 因此在部署的时候，应用和其依赖的系统是整体打包成一个镜像的 后端开发不再依赖运维人员创建程序的运行时环境
2.2.3 微服务
云原生带来的另外一个改变就是微服务 在之前的几年，web应用的主要架构师SOA架构，在一个服务中多个不同的模块构成了一个部署单元，各个模块作为一个整体部署和伸缩 这种架构下往往服务会形成一个很大的代码仓库，大家共同维护一个大型的系统
好处是模块之间的调用不需要通过RPC网络， 但是坏处就是加减机器的时候不能安模块处理 开发的工作也需要多人共同进行充分的集成测试，保证不会把别人的东西改坏
而微服务架构是把模块拆到不同的服务中去，拆分的粒度更细，可以让每个模块独立的更精确的扩容/缩容 同时可以让少数几个人维护一个仓库，更适合敏捷的开发流程
缺点是 不同服务之间要进行RPC通信，网络开销变大；
另外多提一嘴，Martin Fowler的这篇文章是比较著名的一篇介绍微服务的文章，他也是之前我们敏捷宣言的发起人之一，感兴趣的同学可以多去了解一下这个人的文章
云原生让我们的开发环境也逐渐云化 新人入职往往前面几天导师安排的工作就是搭建开发环境 一旦开发环境出了问题，排查和解决起来都非常痛苦 而云原生的IDE就可以很好的解决这个问题 借助容器技术，可以轻松创建一个模拟线上的开发环境 比如你不要再纠结本地多个java的版本，go和python的还有依赖的库也可以随意切换
2.2.4 团队的分支策略
讲完了云原生，接下来影响我们开发的最大因素就是团队的分支策略
不同的分支策略往往影响团队的开发流程 这里假设大家没有深入使用过git，简单介绍一下， 我们日常工作中写代码都是基于主干的某个版本进行修改，改完之后再把代码合并回主干形成新的版本 这里就会有一些协作上的问题： 多个团队成员各自用什么分支？修改有冲突怎么解决？出了问题代码如何回退？
为了应对这些问题： 有些团队会有一个专门的分支叫做release分支，大家都把代码合并到release分支，然后测试，发布，之后再把release分支合会master 有些团队会直接把开发的分支合入master，然后再用某个master上的commit发布 之所以有各种各样的分支策略，就是因为我们在后续的测试和发布阶段要按照对应的分支和commit进行交付
大家在实际工作中，一个项目的分支会变得非常复杂， 因此在团队中一定要统一分支的规则 什么分支是做什么的，每个人都要清楚 并且对于git的知识也是需要重点掌握的
2.2.5 代码规范、自测和文档
一个有经验的开发和新人写的代码，往往最大的差别不是功能的实现，而是在于代码的风格和规范
比如有一些原则可以很容易遵循： 良好的注释习惯，有复杂的地方时间长了自己都会忘 不要有魔法数字和魔法字符串，比如在判断条件里判断某个变量等于2，2代表什么？可以用常量来定义 重复的逻辑可以抽象成公共的方法，不要到处copy代码，不然每次修改都要改很多地方 正确使用IDE的功能进行重构，不要手动去编辑或者全局替换
另外在开发阶段还要进行自测和文档编写， 在开发过程中，随时进行一些静态代码扫描，也能显著提高代码质量 遵守开发的规范就像大家随手捡起手边的垃圾，是一个对团队有益的好习惯
