不懂工作流的程序猿不是好攻城狮
“工作流能使整个开发过程更加顺滑，提高我们开发的效率。”
“从宏观上说，工作流是一个价值流，它在公司的各个部门各个角色间流转，部署到我们的生产环境上，成为一个用户可感可知的东西。”
聚焦“工作流”问题，在 2022 年 1 月 13 日的第三期融云猿桌派上，霜神、孙敬云和主持人臧其龙展开了一场深入讨论。
现在，为各位奉上节目的完整版回放，以便错过直播的同学观摩学习
也欢迎大家关注以下平台，收看/收听节目，获取更多节目信息。
关注融云视频号
融云全球互联网通信云
更多干货信息不定期掉落哦
1 月 20 日（本周四）19：30
第四期猿桌派即将开播，
请大家锁定融云视频号、融云官方微博，
准时收看节目，参与互动~
下面，一起回顾下第三期节目的精彩内容吧～
如何推进工作流？
如何在代码层面推行工作流？
Git Flow 是广泛使用的工作流程之一，有两个主要分支，Master 和 Develop。
Master 分支上每一个节点都代表了一个大版本，每一个大版本发布，都会把代码合并到 Master 上并打上相应的标签。Develop 分支主要是平时开发使用，每当一个需求进来，开发者要针对这个需求建立它的 Feature。
如下图，从 Develop 分支上拉出来很多 Feature，开发完成后会再合并到 Develop 分支上。
每次发版时，要先把 Develop 分支合并到一起，再合并到 Release 分支上。在此之前，需要同组的人先帮你进行 Code Review ，通过后合并到 Release 上，然后通知 QA 去检验这个版本，在各种环境上测试。
如果需要，在 Release 分支上修复 Bug，最终测试完成后，合并到 Master 上进行发布。
如果在 Master 分支上发现这个版本发布到线上有 Bug，就要用到 Hot Fix，在 Hot Fix 上先拉一个分支出来，进行紧急的代码修复，修复完成后，再重新合到 Master 分支上，并且这个代码也得重新合并到 Develop 分支上。
不同规模的公司如何设计工作流？
无论公司规模多大，都无法凭空设计一套工作流，然后要求全公司所有人马上进入到这个模型中来，这是不现实的。
建议可以从一个小团队、组织开始，去重新定义工作内容。比如研发团队，让他们有唯一的工作入口，所有的工作放在这个代办列表里，按照优先级或者其他的策略依次进行消化。慢慢地，这个小团队可以在内部孵化一个适合自己的工作方式和流程，这其实是一个工作流中的点。
这个点形成后，它的上下游协作部门可以慢慢加入，形成一条线，然后再形成一个面。
影响上下游的方式可能是，这个团队把它的入口跟出口定义清楚。比如上下游提出的需求，要按照规定好的文档格式进行。
当每一个节点都有一个标准的输入定义和输出定义，从一个点慢慢的延伸它的上下游。然后工作流的前一个节点，后一个节点，它的上下平行的这些兄弟节点的入口跟出口，定义都会慢慢清晰起来。一个简单的工作流模型就形成了。
这样，公司的行为规范、流程制度都会被沉淀下来，这些会变成标准流程并不断优化。
Code Review 是必选项，不是可选项
为什么要实施 Code Review？
首先，Code Review 的过程，是一个团队成员一起学习跟探讨的过程。
Code Review 的目的绝不是互相挑错，而是学习彼此的 Coding 方式和实现路径，并相互探讨，一起找到更好的解决方案。
其次，Code Review 本质上是要让大家在过程中更加了解项目。
一般情况下，团队执行同一个项目，各有分工，如果不主动看其他成员的代码，基本上项目的这个部分自己是没办法了解的。
在 Code Review 过程中，你会去了解这部分项目背景，即使没有完整实现一遍，也可以了解整体思路。下次有类似需求，你也可以写。整个项目每一个人都能接任何需求，不会出现严重的割裂。
最后，Code Review 可以加快团队融合。
去年开始，融云大举推出第三代场景化 SDK，以 IM+RTC+X 为基础，为开发者提供完整封装、开箱即用的语聊房、直播 SDK，极大减轻开发者的学习成本，提升开发效率。
场景化 SDK 的一个难题便是对通信核心的 IM 和 RTC 能力的融合，这两块都有一定学习门槛，而 Code Review 就可以作为一个相互融合的切入点。
而且，每个开发者的编程风格都各不相同，Code Review 的机制会让大家更在意自己编程中的规范表达，也便于团队形成相对一致的风格。
如何保证 Code Review 持续推行？
首先要先定制度，不经过 Review 的代码合不进去，功能就不能叫完成。这是硬性规定。
然后，要让团队成员理解为什么需要实行 Code Review，这是文化认知上的引导。比如，真正让开发者知道，Code Review 可以帮助他成长，有助于保证项目的代码质量等等。
并且，Review 的时间不要过长，一次 Review 的代码行数不要过多，否则很难保障质量。根据一篇论文的数据，团队内部进行 Code Review，一次建议 200~400 行，时间大约在 60~90 分钟之间，速度建议保持 300~500 行每小时。
最后，当大家在实践中认可了 Code Review 带来的价值，比如线上 Bug 变少了，代码质量变高了，自然会一直坚持执行下去。