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

[caqiko]

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

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

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

[beyondorient]

我身边是写小程序和 APP 的。因为用户不多

[beyondorient]

@beyondorient 手抖了 。

我觉得后端开发，高级的可能是大厂的同学，写算法做优化的。
而写业务代码的就是写 if.. else ..这种各种逻辑判断的吧

[casillasyi]

做了一年的所谓中间件，底层技术。现在觉得还是业务牛逼。直接面对用户的代码挑战是最大的，所谓底层技术，架构，思想，业务里都能用。（我在某网约车公司）

[Jonz]

搞搞框架？中间件？

[EKkoGG]

写业务代码不 low，只会 /一直 写业务代码的很 low

[lincanbin]

作为一个高级增删改查工程师，我自己的观点：

业务代码质量一般比较低，个人认为是需求快速、频繁变化引起的。
历史悠久的成熟业务代码很容易变成一座屎山。
在屎山打滚最好的方式，自然也是往上面糊自己的屎。

在屎山打滚很容易被人觉得 low 吧？

[nicevar]

钱没到位就 low

[ipwx]

@lincanbin 微软要是一直以这个态度开发系统，那它的系统一定漏洞百出。。。。

啊嘞，好像确实曾经有过十年时间，微软的 XP 系统漏洞百出来着？
= = = =

@caqiko 微软都花了十年搞定它“屎山”一般漏洞百出的业务代码，你觉得这种写代码的方式不会让人感觉 low 嘛？

[mcfog]

没有业务代码的迭代试错，哪里来大流量高并发给中间件施展空间？哪里来大数据给算法捣鼓？
没有成熟稳定的基础架构，怎么一周甚至一天发几个版本快速迭代业务？

不仅限于技术角色，QA 产品运营市场等等，都是互相支持互相协同的，都有各自的困难和挑战，傻逼都能拖后腿，牛逼都能带着团队一起前进

反正我觉得很多人默认管理比做事牛逼，做底层比做上层牛逼，是很短浅的认知

[smeraldo]

因为平均水平低

[jiangnanyanyu]

因为绝大多数的人都很水啊

[RqPS6rhmP3Nyn3Tm]

设计模式要用好没那么简单的

[bk201]

年龄越大，越不会说出这种话，刚毕业的蛮多这么认为的。说到底技术只是工具，业务才是目的。

[LxExExl]

5 楼真相了

同样是刚毕业写业务代码 有的人一写就是好几年 有的人第二年就开始自己构思业务 第三年就能指导别人写业务代码了

[glfpes]

不懂业务写业务代码和懂业务写业务代码是两码事

[passerbytiny]

他们看不到，他们还看不懂，他们甚至不知道业务的英文是 Business （商业），于是在他们的眼里你就是个 low。

[victorywangzhcn]

这看你追求啥，不是开地图炮，多数写业务代码的水平都不怎么高（当然面对极其复杂的业务，代码依然能保证良好的抽象层次的大佬除外），你要是追求技术，中间件 /SRE 适合你（客服）。

[VoidChen]

严格来说算法也算业务，所以做业务不 low。。。
low 的是每天都是重复增删查改调别人的 api 那种。。。
你先想想你工作有没有什么难度就知道了

[l00t]

@ipwx #8 微软啥时候搞定过了？

[yangzhezjgs]

写业务代码，通常提高方向只能是提高代码质量，设计模式可读性可维护性之类的，而更底层的知识用的很少，但是中国公司普遍不重视代码质量，只玩加班，进一步导致区分度不够，只会写业务代码的人可替代性很强。
而写 infra （中间件，数据库之类的）的工程师更像是传统行业的工程师，对底层知识要求高，门槛比业务高，需要不断积累经验，并学习新的知识，经验的价值就高很多。

[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 一把梭！