许继充电桩电动摩托,许继充电桩电动摩托车能用吗

摘要： 大家怎么理解“业务代码”？为什么有人觉得写业务代码很low？大家怎么理解“业务代码”？为什么有人觉得写业务代码很low？首先，我认为写业务代码不“low”，但是大部分不假思索拷贝粘...

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

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

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

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

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

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

业务代码不一定low，能完成用户需求的代码就是好代码。

另外，对于我们搞嵌入式软件、EDA工具软件的来说，业务软件反而是更有技术含量的，更具科学意义的代码，而软件可能只是载体，你啥时候透过代码理解了它们背后的物理概念、数学公式，你就超越了程序员，能向科学家又迈进一步。

互联网软件其实也一样，软件实现的是一个业务流程的自动化，你完全可以透过你写的程序还原甲方用户的业务流程，而这种流程是老板制订的，认识会上一个层次，将来可以向老板迈进

有人觉得low

1.可能是觉得没有什么技术含量吧，用的都是一些成熟的技术框架，就是一些增删改查而已，但是这并不意味着写业务代码就很简单，因为这里面包含着业务逻辑，业务逻辑有简单的也有复杂的，如果对业务逻辑业务背景不理解或理解不透就很难实施下去，其实现在很多专家级别的程序员并不是技术有多牛，而是对某个行业领域有比较深刻的理解。

2.还有可能就是内心里对业务就很轻视，这个更是不应该的，因为技术是为业务服务的，是业务让技术变的有价值。

林子大了什么鸟都有，不知道你说的有人是指多少比例的人。我的理解代码可以分为两类：1:工具栏或者框架类2:业务类。写工具类偏重于健壮可拓展可复用；写业务类偏重于逻辑严谨没有漏洞，化繁为简。毕竟有些时候需求或者业务都不甚清楚他们想要的逻辑。有时候复杂的业务流程你捋都不顺，更别说代码写的好了。当然，工具类到高深，工具好用，框架优秀确实需要的技术功底深厚，比业务类要考虑的东西也多，但不代表写业务类代码很low。当然，不管写什么代码，完全***黏贴而不去考虑与实际场景结合，不去想为什么？有没有更好的处理方案是比较low的

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

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

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

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