大家怎么理解“业务代码”？为什么有人觉得写业务代码很low？ _经验知识

在我眼里。也经常会把程序员分成两类：一种是我等这种写业务代码的程序员。另外一种是研究高深算法、造“轮子”的“科学家”...
【大家怎么理解“业务代码”？为什么有人觉得写业务代码很low？】将他们称之为科学家是有些夸张。第一次冒出这样的想法是参加一个技术大会。当别的嘉宾都在分享开发、设计、架构、管理方面的经验时。一名在腾讯工作的算法工程师（应该已经是一个小领导了）。他上台分享了一些诸如：滑动平均自回归模型、神经网络基因表达式编程、SVM回归机集成学习...坐在台下的我第一次冒出这样的念头：“这**是科学家研究的东西吧。”

文章插图
当然。倒也不能说写业务代码就很 low 。写业务代码也不是想象中那么简单的。
写业务相关的代码。必须了解业务流程。还需要了解业务人员心里是怎么想的。也就是业务出发点是什么样子的。
比如我最近遇到一个需求。过程大概是这样的：销售人员在卖一款产品。这款产品非常火。有些优秀的销售人员一周可能能卖出去几百上千单；结果我们接到一个需求。要限制每个代理人的销售数量。比如每人只能卖 10 个（之前已经卖掉的不算）；这就让我们非常奇怪。本来卖的好好的。为什么要做这个限制呢？这个需求看起来就非常的不合理。
后来业务人员和我们解释了一下原因：因为这款产品公司不挣钱。销售人员为了推这个产品。花在别的产品上的时间就少了。所以出这个功能。就是让销售人员“收收心” 。把精力放在其他产品上。
这么一解释。我们就立刻明白了；所以如果你不明白业务的时候。看着需求敲代码也是非常容易出错的。

文章插图
有些人会认为业务逻辑就是一堆 if-else 。但是我认为在实际工作中。这些 if-else 也是非常难做到的。
业务逻辑是人设计的。业务逻辑难不可怕。可怕的是它不严谨和变化快；业务逻辑和那些确定性的东西不一样。比如我们写好的代码 if-else 两个分支。那么再怎么也不会跳出这个范围。业务逻辑就不一样了。它是非常灵活的、不确定的。业务机会来的快消失的也快。我们很难开发出来一套全面的、完善的、灵活的的系统。去应对将来可能会发生的需求。
所以在开发过程中。如果可以将业务流程拆分成多个组件模型。组件和组件配合完成一个完成的业务流程；当业务发生变化或有新业务的时候。只需要重新编排这些组件。或对某一个组件做少量更改。就可以满足业务变化；如果能做到这个程度。也是非常不容易的。
在这个过程中。你需要做到高内聚低耦合。避免过度抽象。从业务流程和动机出发。已满足业务需要为主；既然做不了“科学家” 。我们就努力把业务代码写好把。

文章插图
我将持续分享Java开发、架构设计、程序员职业发展等方面的见解。希望能得到你的关注。

文章插图
其他观点：
首先。我认为写业务代码不“low” 。但是大部分不假思索拷贝粘贴的业务代码比较“low” 。换句话说就是所谓的五年工作经验就是把第一年的工作重复了五遍。
技术人员成长一般有两条线。一条是成为技术专家。一条是成为领域专家。所谓的转管理我理解也就是领域专家。毕竟不懂得领域知识是无法做好管理的。比如说你是互联网金融某个业务部门的leader 。那么你肯定要懂金融。领域知识就是在不断的写业务代码和思考中积累起来。
还有一个问题就是如何定义业务。比如说“实现一个修改订单功能” 。这是一个业务需求。看起来很low 。但是如果业务需求改成“实现一个修改订单功能。要求在有限资源的情况下并发10k 。响应时间不高于10ms” 。那这个需求就有挑战。说这个问题想说明白一件事情。如果做业务不要停留的在业务表面。仅仅满足于实现功能。要主动思考。
最后总结一下。没有最好的技术。只有最适合业务的技术。技术是内功。业务是招式。内功不足。后续成长乏力。没有招式。内功也不能发挥威力。这是也很多互联网创业公司做大了之后要技术转型的原因。