1
beyondorient 2019-03-01 11:21:53 +08:00
我身边是写小程序和 APP 的。因为用户不多
|
2
beyondorient 2019-03-01 11:25:25 +08:00
|
3
casillasyi 2019-03-01 11:29:53 +08:00
做了一年的所谓中间件,底层技术。现在觉得还是业务牛逼。直接面对用户的代码挑战是最大的,所谓底层技术,架构,思想,业务里都能用。(我在某网约车公司)
|
4
Jonz 2019-03-01 11:38:07 +08:00
搞搞框架?中间件?
|
5
EKkoGG 2019-03-01 11:41:04 +08:00
写业务代码不 low,只会 /一直 写业务代码的很 low
|
6
lincanbin 2019-03-01 11:52:08 +08:00
作为一个高级增删改查工程师,我自己的观点:
业务代码质量一般比较低,个人认为是需求快速、频繁变化引起的。 历史悠久的成熟业务代码很容易变成一座屎山。 在屎山打滚最好的方式,自然也是往上面糊自己的屎。 在屎山打滚很容易被人觉得 low 吧? |
7
nicevar 2019-03-01 11:59:36 +08:00 1
钱没到位就 low
|
8
ipwx 2019-03-01 12:00:34 +08:00
|
9
mcfog 2019-03-01 12:08:22 +08:00 1
没有业务代码的迭代试错,哪里来大流量高并发给中间件施展空间?哪里来大数据给算法捣鼓?
没有成熟稳定的基础架构,怎么一周甚至一天发几个版本快速迭代业务? 不仅限于技术角色,QA 产品运营市场等等,都是互相支持互相协同的,都有各自的困难和挑战,傻逼都能拖后腿,牛逼都能带着团队一起前进 反正我觉得很多人默认管理比做事牛逼,做底层比做上层牛逼,是很短浅的认知 |
10
smeraldo 2019-03-01 12:15:36 +08:00 via Android
因为平均水平低
|
11
jiangnanyanyu 2019-03-01 12:22:11 +08:00 via Android
因为绝大多数的人都很水啊
|
12
RqPS6rhmP3Nyn3Tm 2019-03-01 12:35:39 +08:00 via iPhone
设计模式要用好没那么简单的
|
13
bk201 2019-03-01 12:47:06 +08:00
年龄越大,越不会说出这种话,刚毕业的蛮多这么认为的。说到底技术只是工具,业务才是目的。
|
14
LxExExl 2019-03-01 12:53:11 +08:00
5 楼真相了
同样是刚毕业写业务代码 有的人一写就是好几年 有的人第二年就开始自己构思业务 第三年就能指导别人写业务代码了 |
15
glfpes 2019-03-01 12:55:55 +08:00 via Android 1
不懂业务写业务代码和懂业务写业务代码是两码事
|
16
passerbytiny 2019-03-01 12:58:57 +08:00
他们看不到,他们还看不懂,他们甚至不知道业务的英文是 Business (商业),于是在他们的眼里你就是个 low。
|
17
victorywangzhcn 2019-03-01 13:40:23 +08:00 1
这看你追求啥,不是开地图炮,多数写业务代码的水平都不怎么高(当然面对极其复杂的业务,代码依然能保证良好的抽象层次的大佬除外),你要是追求技术,中间件 /SRE 适合你(客服)。
|
18
VoidChen 2019-03-01 13:46:23 +08:00
严格来说算法也算业务,所以做业务不 low。。。
low 的是每天都是重复增删查改调别人的 api 那种。。。 你先想想你工作有没有什么难度就知道了 |
20
yangzhezjgs 2019-03-01 15:46:56 +08:00 1
写业务代码,通常提高方向只能是提高代码质量,设计模式可读性可维护性之类的,而更底层的知识用的很少,但是中国公司普遍不重视代码质量,只玩加班,进一步导致区分度不够,只会写业务代码的人可替代性很强。
而写 infra (中间件,数据库之类的)的工程师更像是传统行业的工程师,对底层知识要求高,门槛比业务高,需要不断积累经验,并学习新的知识,经验的价值就高很多。 |
21
murmur 2019-03-01 15:49:12 +08:00
业务+行业就不 low 了
|
22
amwyyyy 2019-03-01 17:40:56 +08:00
我都准备转业务部门了,现在部门做一些公共服务(短信推送啥的),平时对接的工作更多,很难做出成绩,还不如写业务。
|
23
behanga 2019-03-01 17:46:51 +08:00 1
不写业务代码,做基础架构也很苦的,KPI 都是各种优化,压力也非常大,经常为了优化 10ms 都要想破头,想想之前做业务的时候,到时没有现在这么多烦恼了,各 2 个版本做一轮业务优化,也还是挺舒服的.
|
24
herozhang 2019-03-01 17:49:21 +08:00
坦白的说,绝大多数公司( 90%+)在技术上其实遇不到需要更高技术能力的瓶颈。
例如: 1. 业务量级规模:百万级用户的公司其实没几个 2. 业务内在复杂度:一般复杂都在 B (企业应用什么的),C 相对内在复杂度没那么复杂 3. 业务变动的频繁程度:一般 C 变动更多,B 相对保守稳定 4. 业务的智能化程度:AI ? ML ?还是直接怼 if else 更快更经济? |
25
zy445566 2019-03-01 18:01:12 +08:00
如果架构永远能保持方便快捷,能识别出各种屎代码,拦截屎代码,我当然愿意一直写业务代码。做一个快乐的 CURD BOY。但屎代码种类实在太多,而且屎还会升级,要防止各种各样的屎出现,只能不断优化框架。
我很赞同 13 楼的话:“技术只是工具,业务才是目的。” |
26
ai277014717 2019-03-01 18:11:44 +08:00
没有业务,再有技术有何用。但是做业务久了,还是个做业务的。提升太少。
|
27
ljzxloaf 2019-03-01 18:41:46 +08:00 via iPhone
业务多变,不易积累,所以没有什么壁垒。
|
28
lazyfighter 2019-03-01 18:44:31 +08:00
一天 8 个小时,4 个小时当客服
|
29
caqiko OP |
31
caqiko OP @yangzhezjgs 业务代码写久了确实提升不大了
|
32
caqiko OP 看了大家的回复,我对写“业务代码”有了新的理解:
高质量的业务代码是高级架构 /抽象 /框架技术的基础。 对于一个团队的产品,或者对于一个工程师来说都是这样。 而给别人带来一种“写业务代码很 low ”的印象,一部分是因为大部分工程师的水平太普通,一方面可能是缺乏提升自己的意愿;一方面也可能是所处的客观环境,需求更新过快,整天都忙着实现功能去了。 当然也有一部分是因为有些评论者,他们离业务场景比较远,总是站在一种技术至上的角度,认为时下流行的、大厂使用的就是最好的。 很同意一位网友的回复: **“技术只是工具,业务才是目的。”** |
33
loading 2019-03-01 22:36:13 +08:00 via Android
如果有人觉得业务代码没意思,可以看看登月项目的业务代码。
|
34
ipwx 2019-03-01 23:11:41 +08:00
|
35
caqiko OP |
36
lizhuoli 2019-03-02 00:49:23 +08:00 via iPhone
所谓”业务代码”都是相对的,没有参考系怎么谈。
像操作系统,站在操作系统内核提供方的角度看,上层所有的应用框架,进程服务,都是业务代码,我是为他们服务的。 站在应用框架的角度,具体某一个邮件应用代码就是业务代码,他需要依赖我并且我不会关心具体邮件逻辑 |
37
loading 2019-03-02 05:17:33 +08:00 via Android
没啥好争论的,这个答案可能可以获得较多的认同:
CRUD 一把梭! |