陷入写业务逻辑的程序员如何突破？

技术和业务是相互成就的，技术为了业务而服务，只要业务没有技术也不长久。

没有技术的业务也走不远！

我之前在一个智能交通领域的头部企业呆过几年，这家公司的思路就是扩大销售，增加提成，但是并不重视技术、不重视产品交付，公司的大老板曾经公开说公司的技术人员不重要。

大领导都这么想，整个公司肯定也是这么执行的，虽然有可能是隐形的。比如研发人员的工资相比同行其他公司会更低，对于技术人员有单独的要求，比如加班等。

同时，对于产品的交付也没有精益求精的精神，大部分情况下都是完成任务了事。因为拿到钱的项目需要尽快完成，这样才可以尽快投入到下一个项目中去，这样才有更多的钱进账。

这造成的后果就是，公司虽然是智能交通的头部企业，但是在用户眼中的产品却越做越差，口碑越来越不好，回头客越来越少，收益越来越少。

而对于数据驱动的公司，不管是技术研发还是业务研发，你做的事情，汇报的时候都需要通过量化指标（数据）说清楚价值。

业务研发的价值就是收入、新客、老客、体验等业务指标，那么技术研发怎么说清楚自己的价值呢？

那就是你做的东西，节省了多少成本，为了收入、新客、老客、用户体验贡献了多少比例的价值，有多少业务在使用你做的东西。

所以，陷入业务逻辑不是缺点，而是优点。尤其是 AI 时代，很多技术性质的工作都可以被 AI 替代，但是让 AI 写业务逻辑，它还做不到。

但是，重点的是你真的要熟悉业务、精通业务，能为业务赋能，而不是只会 CRUD！

要做到对业务了如指掌，不合理的产品需求，你能说出来为什么不合理，并予以驳回。

要做到能够为业务指标贡献自己的建议，承担一部分业务指标。做到，即是技术专家，也是业务专家。

技术人员尤其要注意，别唯技术论。

只有能解决公司问题、为业务增长赋能、支撑的技术才是有价值的技术。要记住，公司是以赚钱为导向，不是以技术牛逼为导向。

一个用户不到 100 人的 IT 系统，明明是一个 tomcat 单体服务就能搞定的事情，你去用分布式、微服务，那不是杀鸡用牛刀嘛？而且分布式系统、微服务系统的维护成本相比于单体系统至少高 10 倍。

一个例子是，淘宝技术架构的演进

2003 年，第一个版本的淘宝是花了 3000 美金买的，工程师简单处理之后直接上线的。就是一个 Linux + Apache + MySQL + PHP 架构。

2004 年，淘宝业务飞速发展，用户数和商品数暴增，而电子商务网站又以业务复杂度著称，原有的技术架构严重阻碍的业务发展。之后，在 SUN 公司的技术顾问的协助下进行了架构重构，实用了 Java + Oracle 的架构，实用 MVC 框架和 IBatis 框架，解决了视图与业务逻辑分离的问题和对象与关系数据库解耦问题。

这个阶段，淘宝使用 Weblogic 服务器和 Oracle 数据库等收费产品，从而让有限的资源投入到新业务开发上，而不是基础技术上，就是理所应当了。

之后业务发展迅猛的三四年，淘宝一直使用的都是这些成熟产品。

再之后，淘宝业务成熟稳定之后，才在技术领域开始发力，许多奠定淘宝坚实架构基础的产品和技术才开始逐步发展，但这也是因为业务的需要，业务规模上去了之后，原有的技术已经满足不了业务需求了。

这之前，淘宝的技术也只是没有拖业务后腿的水平而已。

业务是价值所在，技术支撑着业务的发展，熟悉业务并不是缺点，而是必然！