业务代码和技术代码

在我眼里，程序员往往分为两类:一类是写业务代码的程序员，一类是研究高级算法、造“轮子”的“科学家”...

他们称科学家有点夸张。他们第一次产生这个想法是参加一个技术会议。当其他嘉宾在分享他们在开发、设计、架构、管理方面的经验时，在腾讯工作的算法工程师(应该是个小领导)上台分享了一些想法如:移动平均自回归模型、神经网络的基因表达式编程、SVM回归机的集成学习...坐在观众席上，我第一次有了这个想法。

当然也不能说写业务代码就很低，写业务代码也没有想象中那么简单。

写业务相关的代码，必须要知道业务流程，还需要知道业务人员是怎么想的，也就是业务的出发点是什么样子的。

比如我最近遇到一个需求，流程大概是这样的:销售人员在销售一个产品，很受欢迎，有些优秀的销售人员一周可能能卖出几百或几千单；结果我们接到一个需求，要求限制每个代理商的销售数量，比如每人只能卖10个(不算之前已经卖出去的)；这让我们很奇怪。本来卖的还不错。为什么要做这个限制？这个要求似乎很不合理。

后来业务人员给我们解释了原因:因为这个产品公司不赚钱，销售人员为了推这个产品，花在其他产品上的时间比较少，所以这个功能就是让销售人员“收心”，专注于其他产品。

有了这个解释，我们立刻明白了；所以如果你不了解业务，在看需求和打代码的时候也是非常容易出错的。

有些人会觉得商业逻辑只是一堆if-else，但我觉得在实践中，这些if-else也是很难做到的。

业务逻辑是人设计的。难还是不可怕？可怕的是不严谨，变化快。业务逻辑不同于那些确定性的东西，比如我们写的代码if-else的两个分支，所以永远不会跳出这个范围。商业逻辑是非常灵活和不确定的，商业机会来的快，去的也快。我们很难制定一个全面、完善、灵活的体系来应对未来可能出现的需求。

因此，在开发过程中，如果可以将业务流程拆分成多个组件模型，组件与组件之间就可以协同完成一个完整的业务流程；当业务发生变化或者有新的业务出现时，你只需要重新排列这些组件或者对某个组件做少量的改动就可以满足业务的变化；如果能做到这种程度，也是很难的。

在这个过程中，你需要做到高内聚低耦合，避免过度抽象，注重从业务流程和动机上满足业务需求；既然做不了“科学家”，那就努力把业务代码写好。

我会继续分享我对Java开发、架构设计、程序员职业发展等方面的看法。希望能引起你的注意。