关于开发流的一点思考

前言

突然想聊聊开发流的东西，可能在一个新的环境下对之前的整个开发流程有了些思考，思考什么？

我所理解的一个高效的开发流程应该是什么样的？

实际工作也有四年了，做互联网开发也三年了，所以自然而然对整个软件开发流程有了些自己的想法和理解。对于我所理解的开发流程要有如下的特点：

如下图，是我整理的我所理解的一套开发流程：

上图中，我们在开发过程中随着时间线的前移，我们犯错的概率尽可能的集中在前面。另外，图中淡紫色的图标是在我目前的开发流程中没有或者体现的并不明显的地方。

为什么需要技术评审？当然这里需要技术评审的应该是一些体积大或者影响面比较大的项目，具体的评判标准就依环境而定了。

技术评审的目的，一方面，开发人员向负责人和相关人员同步具体的技术实施方式，是一个信息同步的过程；另一方面，负责人或相关负责人对技术方案进行评估，毕竟负责人和相关人员是对系统整体了解最透彻的人，从而避免未来项目开发完了或者上线了才发现一些比较大的问题。

最后，技术评审通过后，相应的开发人员写代码也可以一蹴而就，安安心心的码代码，是吧？

建模也不是我第一次谈到了，具体的实例在我之前的文章里也能找得到，我为什么这么强调建模？因为建模(就是抽象)之后写出来的代码往往思路清晰，高可扩展。

①commit代码前diff代码　②merge代码前diff代码　③上线前多人diff代码

以上是我一定会去diff代码的场景，目的很简单，一：是不是误提交了代码　二：简单的code review

code review 的最佳时间我一般建议是开发完成时或联调阶段，因为这段时间业务代码基本是一个稳定的版本了。至于这个时间之前，代码不稳定；至于这个时间之后，review出问题再修改代码的成本(浪费测试的时间)会比较高。

目的很简单：和每一位涉及的开发人员核对每一行代码的变动，防止误提交被发布到线上。

这个一般出现在多项目上线的情况，涉及多项目的发布依赖关系，为了保证最终按正确顺序的串行上线。把上线的推进权利集中到一个人的手上，梳理并核对发布顺序，最终完成上线。

例如后端系统的话，观察系统的3xx、4xx、5xx异常日志曲线在上线后是不是有突然的上升趋势来判断我们的上线是否正常。

扫面下方二维码关注我的技术公众号，及时为大家推送我的原创技术分享

图片描述