入职大厂，做基础架构中间件开发，对职业发展有好处吗？未来发展方向应该怎么选？

[arloor]

个人以前觉得做业务的天花板太低了，一直觉得业务大部分工作都是 curd 。只有要求比较高的情况下，才可能会遇到真正需要能力才能解决的问题。

相比之下，个人认为基础架构更能提高能力。但是，在脉脉看到“还是做业务有前途啊”这样的说法，所以有点迷惑。

• 在大厂做基础架构，跳槽别的厂认这个吗

• 以后还是要转业务吗？能不能一直做架构大头兵？或者跳出去能不能当业务开发 leader

[hdbzsgm]

基础架构做到最后 容易做成运维 锅多 绩效低

[kop1989]

架构小弟的问题主要是
1 、各厂之间不通用，作用面窄。2 、很难直观体现你的价值。
业务的优势主要在于业务、技术两把抓。因为 IT 的核心生产资料是把业务信息化、数据化的能力。

[keshawnvan]

路一般会越走越窄，工作也会经常当客服。如果已经有类似的产品再使用，推行你们新的中间件也会比较困难。

[acthtml]

如果走技术路线，基础架构部门容易晋升。
如果走管理路线，业务条线更宽。

[fxxkgw]

在大厂做基础中间件 5 年的人表示：太难了，大部分时间是客服（不要指望说有专人负责，不可能的），另外各种背锅。。。

[arloor]

@fxxkgw 大佬跳槽的话想做什么啊

[fxxkgw]

欢迎参加各种故障分析会，很多研发领导都是老油条，会玩文字游戏，一万种手段让大家觉得是你基础中间件做的不好导致的问题，哪怕是很明显的他们的配置错误，也会说你没提示没检查出来也有问题。。你能说啥呢，回去加 if else 或者 assert 吧

[fxxkgw]

@arloor 然后我现在真的去做运维了 成了全职客服

[gaigechunfeng]

@fxxkgw 我体会到这种痛苦了。一般错误，出了明显的前端页面显示错乱，逻辑性的东西都可以说是底层没做，底层做的不智能，底层没有提示，底层不够友好。

背锅与否，一般看吵架能力，但往往做业务的产品经理吵架技能都是点满的。

所以理解底层要去加各种不合理的容错判断和条件。

[muntoya]

业务的需求千变万化，一般直接面对外部用户，所以很容易因为赶需求频繁加班。
基础架构的技术基本是通用的，意思是说相对于业务，底层技术可以用在更多项目上，一般也有更多时间调研和设计。
所以如果喜欢技术，爱写代码，基础架构倒是更好的选择。

[KaynW]

@fxxkgw 进你们厂当客服技术栈需要啥

[linghutf]

客服，主业是运维

[HashV2]

我觉得最后总归是要回归业务的

[Thresh]

业务 业务 业务

[StickmY]

还是业务好。infra 如果不是从头做起，很容易做成客服。从绩效角度讲，也是业务比架构的机会更大一些，其实职位越向上，越靠近业务，不管是什么岗位，往上跑都需要业务 sense

[slyang5]

@fxxkgw 贵厂客服 需要什么技能 ？

[mogami18]

给楼主打打气，我之前 24 岁的时候在国内北京某家外卖公司做分布式 TensorFlow 平台的系统优化，还是能学到很多东西的。上班就是读 paper，改系统的代码，跑 benchmark，带应届生。感觉还可以。不过人各有志，我最后还是 ym 了北美

[index90]

今天才思考过这个问题，看你在哪个方面看，如果是收入角度，那么和我以下说的无关。毕竟行行出状元嘛。

做底层架构开发，其实很类似搞科研，在某一个技术领域钻研，钻精。你的圈子可能会越来越小，毕竟你成为了那几个拔尖的人才，简单来说就是深度发展。

做业务开发，相对来说会提高涉猎面，你有可能往业务架构发展，往产品，售前，销售等业务线发展，接触的人或者社交圈子相对较大。简单来说就是广度发展。


不过也没有绝对的，做业务开发，不关心业务，只守着一亩三分田，也不会广度发展的。做底层开发，时间安排得好，社交圈子也可以扩大的。

[xmuliushuo]

业务不只是 crud，搞基础架构也不见得比做业务成长更快，两者各有千秋，关键还是看你以后想走什么路线。如果一直做基础架构，除非你业务 sense 非常好，否则很难直接去当业务开发的 leader，因为业务 leader 不仅仅需要技术能力，还需要其他的业务能力（比如产品思维、业务把控等等），这些能力做架构可能很难得到锻炼提升。

[CoderGeek]

技术也得往业务靠拢 大公司每个都自己有一套
技术当然是有积累的 不过嘛 LZ 说的没错
有的搞着搞着就运维技术支持了