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

[caqiko]

我理解的业务代码就是写后台逻辑。

就我的认知，应该大部分的后端开发都算是写业务代码的吧？

为什么有人会觉得这个很 low 呢？
后端开发，除了写业务代码还能是啥？

[murmur]

业务+行业就不 low 了

[amwyyyy]

我都准备转业务部门了，现在部门做一些公共服务(短信推送啥的)，平时对接的工作更多，很难做出成绩，还不如写业务。

[behanga]

不写业务代码,做基础架构也很苦的,KPI 都是各种优化,压力也非常大,经常为了优化 10ms 都要想破头,想想之前做业务的时候,到时没有现在这么多烦恼了,各 2 个版本做一轮业务优化,也还是挺舒服的.

[herozhang]

坦白的说，绝大多数公司（ 90%+）在技术上其实遇不到需要更高技术能力的瓶颈。

例如：
1. 业务量级规模：百万级用户的公司其实没几个
2. 业务内在复杂度：一般复杂都在 B （企业应用什么的），C 相对内在复杂度没那么复杂
3. 业务变动的频繁程度：一般 C 变动更多，B 相对保守稳定
4. 业务的智能化程度：AI ？ ML ？还是直接怼 if else 更快更经济？

[zy445566]

如果架构永远能保持方便快捷，能识别出各种屎代码，拦截屎代码，我当然愿意一直写业务代码。做一个快乐的 CURD BOY。但屎代码种类实在太多，而且屎还会升级，要防止各种各样的屎出现，只能不断优化框架。

我很赞同 13 楼的话：“技术只是工具，业务才是目的。”

[ai277014717]

没有业务，再有技术有何用。但是做业务久了，还是个做业务的。提升太少。

[ljzxloaf]

业务多变，不易积累，所以没有什么壁垒。

[lazyfighter]

一天 8 个小时，4 个小时当客服

[caqiko]

@casillasyi
@Jonz
@EKkoGG

看了你们的回应，我知道了除了只实现业务功能之外，还可以搞搞框架，和轮子什么的。

但是感觉小厂的开发人员配置比较紧张的话，也很难有时间做这些吧？

[caqiko]

@lincanbin
@ipwx

微软这种写操作系统的也算是业务代码？？我觉得写操作系统的需要很强的抽象能力。

[caqiko]

@yangzhezjgs 业务代码写久了确实提升不大了

[caqiko]

看了大家的回复，我对写“业务代码”有了新的理解：

高质量的业务代码是高级架构 /抽象 /框架技术的基础。
对于一个团队的产品，或者对于一个工程师来说都是这样。

而给别人带来一种“写业务代码很 low ”的印象，一部分是因为大部分工程师的水平太普通，一方面可能是缺乏提升自己的意愿；一方面也可能是所处的客观环境，需求更新过快，整天都忙着实现功能去了。

当然也有一部分是因为有些评论者，他们离业务场景比较远，总是站在一种技术至上的角度，认为时下流行的、大厂使用的就是最好的。

很同意一位网友的回复：

**“技术只是工具，业务才是目的。”**

[loading]

如果有人觉得业务代码没意思，可以看看登月项目的业务代码。

[ipwx]

@caqiko 其实我觉得本来就没有什么“业务代码”的严格区分。

就如 @loading 所说的，登月项目的代码是不是业务代码呢？是的话，谁是需求方呢？

同样地，操作系统不算业务代码嘛？用户的需求不是需求嘛？

[caqiko]

@ipwx 我现在对“业务代码”的理解，在于开发人员是否总是站在一个比较低的层面，仅仅为了实现需求而写的代码，虽然实现了功能，但是代码质量或者说工程质量可能是很挫的。

与之对应的是，开发人员站在更高的层面，自上而下的设计代码，有更强的抽象能力，有更好的伸缩性。

看了上面这些网友的回复，我觉得对于一个普通的开发人员，整天忙于迭代功能的情况下，很难跳出来，做到后者。

@loading 提到的探月工程和前面说的操作系统，这些复杂的大型项目，如果只靠这些站在低层面看问题的人，我觉得会出很多问题。

[lizhuoli]

所谓”业务代码”都是相对的，没有参考系怎么谈。
像操作系统，站在操作系统内核提供方的角度看，上层所有的应用框架，进程服务，都是业务代码，我是为他们服务的。
站在应用框架的角度，具体某一个邮件应用代码就是业务代码，他需要依赖我并且我不会关心具体邮件逻辑

[loading]

没啥好争论的，这个答案可能可以获得较多的认同:
CRUD 一把梭！