业务和代码质量的平衡

业务和代码质量的平衡,我觉得是跟业务强相关的,所以每类业务,每个团队的情况可能都不同。我这里只说说我们这边的情况,也欢迎其他同学补充自己所在团队的情况。

我们这边,从整体上看,是对业务进行了等级划分,分成三类:

  1. 新业务

  2. 稳定业务

  3. 核心业务

对于新业务,需要的是迭代速度,需要快速验证产品方向,所以对代码的质量要求比较低。底线是能够正常运行。

对于客户端来说,你的代码出问题,不要影响到整体就行;对于后台来说,因为都是微服务,偶尔的 core 或内存泄漏,都可以容忍,用运维脚本拉起来就是。

新业务这部分的开发工作,也更多由新人来承担。一个是没有历史的业务负担,新人更容易上手;二是代码质量,服务质量要求比较低,不会给新人造成太大的压力。

像前段时间发布的朋友圈动态,近段时间发布的好物圈都可以算是新业务。

一般,一个新业务上线后,如果业务数据比较好,功能受到用户的喜欢,都会再快速迭代一段时间。一段时间后,业务需求,用户量等各方面都趋于稳定了,就进入到了稳定业务的行列。当然,也有很多新业务最后是直接死了,那部分代码就没怎么维护了。

新业务成长为稳定业务后,大部分情况下,会进行一轮较大规模的重构。因为前期迭代的速度很快,无论是代码设计还是架构设计,都会存在不少的问题,这个重构就是为了解决掉前期遗留下的技术债。有时候,重构还不止一次。

稳定业务的需求变化相对新业务少了,迭代节奏也会慢下来,开发的周期可以更长,所以质量要求也会相对高了。像现在的看一看,可以算是稳定,但还不是核心的业务。

稳定业务继续往前发展,最后有可能会成为核心业务。

核心业务的需求变化极少,这类业务的体量通常已经很大了,对代码质量的要求会高很多。

代码提交前,要做交叉review , 跑单元测试用例,代码的权限控制也很严格,只有特定的人可以修改。

像消息和朋友圈就是最核心的业务了。在消息系统的内部,代码还有进一步的划分。保证消息去重和时序性的代码是最核心的,新消息样式的代码,质量要求又相对低很多。

以上就是我们这边大概的情况。这种划分挺利于团队人员的分工合作,我觉得互联网产品的系统,都可以采用这套机制。

本文来自【大飞码字的朋友们】,欢迎加入。

-------------本文结束感谢您的阅读-------------
Laic Zhang wechat
欢迎关注博主微信公众号【laiczhang】