遇过大事后才能意识到code review的重要

Posted 2022-01-08 Sam_Deep_Thinking

概述

最近团队出现了不少大故障，让我重新思考了团队的职能，之前也努力的思考过，但是不够深入且缺少实际的场景。经过最近的故障后，才明确了团队的职能：

稳定、安全和准确。

团队是负责订单、支付的，且有门店线下茶饮业务，这里我统称为交易线。交易线一旦出问题，是会直接导致全世界的门店都乱成一团的，比如说门店店员无法查看订单，无法通知用户取茶，杯子上的杯贴打印不出来或者打印的你内容有误等。

交易线出了问题，跟其他职能团队是不同的，比如说跟商品组，会员组等，这些职能团队出了故障后，可能回滚一下就完事了。但是订单的不同的，就算回滚了，还一大堆手尾要处理，比如说，退款、用户投诉，门店投诉，要好一阵子，门店的人才能开始专注去做事。这就是为什么有门店线下茶饮业务的，订单的，一定要稳定好用的原因。

至于安全，说的是支付这个业务，支付都是很有可能被人刷的，一旦没有做好安全措施，分分钟就会造成资损故障，且金额还不小呢。一旦出现了这种故障，就算你平时表现再好，也都没用了。因为故障太严重了。

而准确说的是，数据落地和推送给下游的时候，要准确。不准确的话，就会有几个问题，比如说，大数据团队数据不准，门店茶饮杯子上的杯贴内容不对，订单销售数据也不对，财务数据也不对。

团队的职能考虑清楚了，加上平时的故障的复盘，其中有一个重要的体会，那就是需要做code review。无论需求大小，必须有详细设计，开发人员在提测相关的代码时，必须强制做code review。把code review作为一项重要的工作去对待。

基于以上的实际情况，重新给团队做了一些简单的流程：

1、无论需求大小，需要有详细设计，好的代码真的是设计出来的，需求一来就写代码，是不好的习惯；
2、代码提测前，必须发需要code review的邮件，由相关的人详细查看代码，觉得ok了，才能提测；

可能有人会说，这样会降低项目交付的速度的，但是我想说的是，你要看自己团队本质的职能是什么，负责的是什么业务。像交易服务的，真的是要慢要质量，而不是图快。因为一旦出事，影响实在太大了。