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

Posted Sam_Deep_Thinking

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了遇过大事后才能意识到code review的重要相关的知识,希望对你有一定的参考价值。

概述

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

稳定、安全和准确。

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

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

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

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

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

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

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

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

以上是关于遇过大事后才能意识到code review的重要的主要内容,如果未能解决你的问题,请参考以下文章

phabricator + gitlab 强制 code review

华为首次自曝“天才少年”成果:入职不到一年就干成这件大事,网友:值200万年薪!...

Python3 From Zero——{最初的意识:000~Initial consciousness『REVIEW』}

你有做 Code Review 吗?

自动化 Code Review

自动化 Code Review