大家怎么理解“业务代码”?为什么有人觉得写业务代码很low?
首发

大家怎么理解“业务代码”?为什么有人觉得写业务代码很low?

优质
请用语音读文章

热门回答:

在我眼里。也经常会把程序员分成两类:一种是我等这种写业务代码的程序员。另外一种是研究高深算法、造“轮子”的“科学家”...

将他们称之为科学家是有些夸张。第一次冒出这样的想法是参加一个技术大会。当别的嘉宾都在分享开发、设计、架构、管理方面的经验时。一名在腾讯工作的算法工程师(应该已经是一个小领导了)。他上台分享了一些诸如:滑动平均自回归模型、神经网络基因表达式编程、SVM回归机集成学习...坐在台下的我第一次冒出这样的念头:“这**是科学家研究的东西吧。”

当然。倒也不能说写业务代码就很 low。写业务代码也不是想象中那么简单的。

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

比如我最近遇到一个需求。过程大概是这样的:销售人员在卖一款产品。这款产品非常火。有些优秀的销售人员一周可能能卖出去几百上千单;结果我们接到一个需求。要限制每个代理人的销售数量。比如每人只能卖 10 个(之前已经卖掉的不算);这就让我们非常奇怪。本来卖的好好的。为什么要做这个限制呢?这个需求看起来就非常的不合理。

后来业务人员和我们解释了一下原因:因为这款产品公司不挣钱。销售人员为了推这个产品。花在别的产品上的时间就少了。所以出这个功能。就是让销售人员“收收心”。把精力放在其他产品上。

这么一解释。我们就立刻明白了;所以如果你不明白业务的时候。看着需求敲代码也是非常容易出错的。

有些人会认为业务逻辑就是一堆 if-else。但是我认为在实际工作中。这些 if-else 也是非常难做到的。

业务逻辑是人设计的。业务逻辑难不可怕。可怕的是它不严谨和变化快;业务逻辑和那些确定性的东西不一样。比如我们写好的代码 if-else 两个分支。那么再怎么也不会跳出这个范围。业务逻辑就不一样了。它是非常灵活的、不确定的。业务机会来的快消失的也快。我们很难开发出来一套全面的、完善的、灵活的的系统。去应对将来可能会发生的需求。

所以在开发过程中。如果可以将业务流程拆分成多个组件模型。组件和组件配合完成一个完成的业务流程;当业务发生变化或有新业务的时候。只需要重新编排这些组件。或对某一个组件做少量更改。就可以满足业务变化;如果能做到这个程度。也是非常不容易的。

在这个过程中。你需要做到高内聚低耦合。避免过度抽象。从业务流程和动机出发。已满足业务需要为主;既然做不了“科学家”。我们就努力把业务代码写好把。

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

其他观点:

首先。我认为写业务代码不“low”。但是大部分不假思索拷贝粘贴的业务代码比较“low”。换句话说就是所谓的五年工作经验就是把第一年的工作重复了五遍。

技术人员成长一般有两条线。一条是成为技术专家。一条是成为领域专家。所谓的转管理我理解也就是领域专家。毕竟不懂得领域知识是无法做好管理的。比如说你是互联网金融某个业务部门的leader。那么你肯定要懂金融。领域知识就是在不断的写业务代码和思考中积累起来。

还有一个问题就是如何定义业务。比如说“实现一个修改订单功能”。这是一个业务需求。看起来很low。但是如果业务需求改成“实现一个修改订单功能。要求在有限资源的情况下并发10k。响应时间不高于10ms”。那这个需求就有挑战。说这个问题想说明白一件事情。如果做业务不要停留的在业务表面。仅仅满足于实现功能。要主动思考。

最后总结一下。没有最好的技术。只有最适合业务的技术。技术是内功。业务是招式。内功不足。后续成长乏力。没有招式。内功也不能发挥威力。这是也很多互联网创业公司做大了之后要技术转型的原因。

其他观点:

业务程序开发相对于底层基础架构层的程序开发有所不同:

业务开发的时间比较紧。变化快。

这个特点导致程序员没有时间重构代码。或者不愿意重构代码。而是用最简单粗暴的复制黏贴的方式快速实现业务逻辑。其实所有的复制黏贴都意味着需要重构。

底层系统的开发。一般是架构师和高级程序员来设计和控制项目时间。相对来说。开发周期长。变化缓慢。会更加注重架构的合理性和稳定性。而且会不断重构和改进。

业务开发一旦完成。只要平稳运行就不会有人再回来补技术债务。不会把它写得更好。除非这个业务爆发了。不得不从新架构以支持更高的并发。如果上线之后表现不佳。很可能下线不再维护。所以公司也不太愿意花太多精力在一个还没有被市场认可的产品项目上。

而底层架构框架的项目会在不同的产品项目中不断应用。不断地进化。就像Spring之类的开源框架一样。不断的升级和完善。

相对来说。业务开发程序员会花大量的时间学习和理解业务知识;而底层框架程序员更多的时间在学习技术架构。如果业务知识在行业内通用。比如财务。金融行业知识。那么长期的积累对业务开发也是很有帮助的。如果业务是很小众的。甚至。这几个月做这个业务。下半年又做另一个业务。做的时候也一知半解。就像很多外包一样。那就没有什么业务沉淀了。

以上就是由优质生活领域创作者 生活常识网 整理编辑的,如果觉得有帮助欢迎收藏转发~

分享到 :
相关推荐

历史上哪个朝代对中国领土的贡献最大?

请用语音读文章热门回答:中华民族的版图不是一天一夜形成的。更不是充话费送的。事实[&...

拼多多的东西有假货吗?

请用语音读文章热门回答:其他观点:拼多多上卖的都是假货和垃圾东西。曾经在一个叫[&h...

能分享一下你们家乡的春天景色的照片吗?

请用语音读文章热门回答:虽不在武汉。也不敢乱串。即使想去串。手里没有钱。只能在随[&...

最强王者“最强”两字完全就是一个笑话,王者段位和“最强”没有任何联系,你认同吗?

请用语音读文章热门回答:你好。我也认为王者段位和最强没有什么关系。王者只是一个段[&...

发表评论

您的电子邮箱地址不会被公开。

评论(2)

  • 长空夕醉 永久VIP 2022年10月1日 06:21:39

    业务,代码,架构,需求,程序员,产品,技术,逻辑,时间,组件

  • 风流种 永久VIP 2022年10月1日 06:21:39

    没想到大家都对大家怎么理解“业务代码”?为什么有人觉得写业务代码很low?感兴趣,不过这这篇解答确实也是太好了

  • 一桥孤寂 永久VIP 2022年10月1日 06:21:39

    在我眼里。也经常会把程序员分成两类:一种是我等这种写业务代码的程序员。另外一种是研究高深算法、造“轮子”的“科学家”..