关于开发流的一点思考

前言

---

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

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

我所理解的开发流

---

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

• 尽量的把问题暴露在开发时间周期的前期(凡事无完美，尽量的想一些措施作好辅助便可)
• 养成好的开发习惯去避免犯错

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

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

须要单独说说的地方

---

1、技术评审

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

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

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

2、代码建模

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

3、习惯性我的diff代码

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

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

4、code review

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

5、上线前多人diff代码

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

6、上线流程

这个通常出如今多项目上线的状况，涉及多项目的发布依赖关系，为了保证最终按正确顺序的串行上线。把上线的推动权利集中到一我的的手上，梳理并核对发布顺序，最终完成上线。

7、异常监测

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

扫面下方二维码关注个人技术公众号，及时为你们推送个人原创技术分享