电商软件开发工作的三种范式

这篇文章的想法来源于我在团队内部的一次分享，觉得可以单独提炼出来，和大家一起探讨。

本文共 1174 字，阅读大约需要 4 分钟。

虽然在同一家电商公司，攻城狮做的都是码代码的工作，但是由于业务背景不一样，工作开展的方式、推进的周期以及产出的形式都不太一样，我在这里称之为：软件开发范式。

我总结了三种常见的软件开发范式，如下图：

流量抓手（Traffic Capturer）：典型的场景是前端业务，需要快速迭代、快速试错，不断尝试各种玩法，即使今天开发的功能，在明天会被其他新玩法取代，但仍然要及时上线，只为抓流量，吸粉丝，涨 DAU。

优势：成果反馈及时明显。不足：重玩法，但积累不够深（业务和技术都是）。

效率提升器（Efficiency Promoter）：典型的场景是中后台、大数据或供应链，产品形态迭代周期较长，需要根据使用情况不断打磨，利用规模效应，实现运营效率提升。

优势：有利于培养业务背景，积累综合能力。不足：强依赖于应用规模，规模小时收益不明显。

机器驯养师（Machine Tamer）：典型场景是运维开发，包括持续发布、容器及中间件等，技术通用性及扩展性强，各种规模的团队都必备。

优势：技术硬通货，门槛高。不足：前端业务感知较弱，而且未来云化是趋势。

三种软件开发范式放在一起，也有交集，会有专有领域的应用，如下图：

Traffic Capturer + Machine Tamer：强调的是在业务容量可变下的弹性部署规划能力，催生的是弹性计算、容器云等技术。

Traffic Capturer + Efficiency Promoter：产生数据产品的专门需求，以精细化数据运营为基础，强调数据应用的完整闭环（计算/展示/推荐/应用）。

Machine Tamer + Efficiency Promoter：由此兴起DevOps的自助式开发运动，以提升开发效率为目标，对管理机器自助运维提出新的要求。

最近国外不是兴起把攻城狮划分为两类的思潮么，具体分类是：

Infrastructure Engineering：软件重工业，专注软件基础设施开发，各种云计算、容器、部署、内容分发甚至 AI 接口，都做成成熟的产品。

Business Engineering：软件轻工业，专注于业务开发，利用好技术解决实际问题，与业务结果同生死共荣辱。

把这两类划分加到软件开发范式上呢，就是大概这个分类：

至于三种软件范式相交的领域，会是什么呢？

好的理论，不仅能概括已经存在的事实，还能推断出即将发生或未知的东西。但是我暂时还想不出，欢迎大家一起讨论。

说不定还能像当年海王星被发现的过程一样，是基于数学预测而非有计划的观测发现出来的，哈哈。

以上