初级前端的离职碎碎念

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

这是一个创建于 1590 天前的主题，其中的信息可能已经有所发展或是发生改变。

我在字节这一年

17 年毕业双非渣前端，19 年初跳槽到字节

tldr

过去一年自己的成长过慢，最近对自己成长的焦虑感越来越强，所以选择离职出来看看。

以下信息均与对前 /现 /将来的老板所述一致。

本人可以接受加班，若对加班 /内卷 /工贼行为感到不适，请及时关闭页面。

我现在依旧觉得字节会是内地发展最快的公司，前景十分好，能从腾讯手上啃下用户时间的都不简单。

没有啥绝对的好与不好，只有适不适合自己，值不值而已。

仅为个人感受，不同的人体验应该会不一样。

去年跳槽的原因

第一份工作做了两年（实习的时候就在了），大部分时候是面向内部员工的系统，天花板肉眼可见，业务场景单一，自感成长空间已经不大。

19 年初的字节给人发展势头很猛的感觉，想去看看。

现在离开的原因

在字节我应该算小程序工程师，业务上用到的库主要是 wepy+redux，一个非常细分的小业务线。

平时看分享比较多的可以回顾下，快手某员工某次分享对小程序的技术评价 :)

排查问题链路过长，运营去年投诉过响应慢，但是这个业务上面向终端用户只有我一个前端，排查问题非常吃力，且消耗时间。吃力分很多维度

用户问题需要一个 case 一个 case 看，归纳困难
链路长，某次，一个问题追查到最后是 rust SDK 的一个时序问题（？），这个问题花费了我一天的时间，持续的推动上游的上游的上游团队定位问题让我感到痛苦（花了很多时间，但是你的业务产出几乎没有）
我依赖的直接上游提供的客户端 API 质量堪忧
有些东西大家没接触过，去年我看了很多 iOS/Android 的文档，就为了定位一个小问题
iOS 13.0 ~ 13.2 糟糕的质量，导致一个问题我来回跟进了得有两个月，不断逼迫我的上游增加埋点，还要联系字节内的用户用测试包测试，最后发现是 iOS 的问题，当时对那个 iOS 开发的态度有点糟糕，感觉有点不好意思

垃圾 wepy 毁我青春。

累和加班其实不是啥大的问题，糟糕的是，劳累的一天结束后，我今天做了什么？累的原因是什么？我今天的成长在哪里？这种微妙的迷茫感充斥着我。

无法从工作上获取成就感+糟糕的问题排查体验+正好有人打电话问要不要看看新机会，促使了这次离职。

为什么不换个业务线看看呢？

离职的时候和 leader 聊了大概 40 分钟，看法并未得到统一，对新饼并不感兴趣。

其实按来之前的 JD，我也没想到我要做的业务是这样子的。。。

字节那些有趣的地方

内网有个 ByteKM，上面有些分享很厉害，也很有趣。

之前故障发全员邮件，过滤器把 p0 故障筛选出来，特别下饭。

使用上的问题感觉响应很快速，我反馈的 bug （非我业务上游，一些 app bug ）感觉很快就有修复。

实名表扬下 starling，我觉得很好用。

Data 系统惊人的好用。

但是有些内部系统的前端一言难尽，你能看到 react 里面的 key 是 [object Object]。

包饭其实是个让人纠结的事情，吃多了会胖，吃少了感觉亏。

现在觉得可惜的地方

今天账号被停用的时候想起芝士计划的 E 卡没有兑换，血亏。

最后三个周匆忙做了重构（ wepy 到 taro ），只验证了主流程，其他流程和样式还存在很多问题，感觉对不起接锅的小姐姐 :(

字节

wepy

问题

iOS

45 条回复 • 2021-11-18 01:54:19 +08:00

fhsan

2020-06-29 22:01:24 +08:00

一个 api 三天写好，前端文档三天还没看懂

aaronlam

2020-06-29 22:07:55 +08:00

但是从言语中还是感觉楼主很强呀，能否给一点初级前端发展的建议。

azh7138m

2020-06-29 22:09:37 +08:00

@fhsan
三天写好？出了问题，我一个业务方，跑版本数据，来告诉客户端是哪个版本改崩的？
然后我的代码里面就充斥这奇怪的兼容代码
什么某个版本启动的时候不能调用 X API，Android 会 crash
什么版本之前切后台时要清理定时任务，Android 会 OOM
什么版本之后，iOS 你要标记用户是因为什么切入后台的，因为这个版本开始，JS 执行会直接暂停，会污染统计数据
我一个前端，一个业务方，是遭了什么罪，得去给客户端三天写好的 API 做这些兼容？

lovedebug

2020-06-29 22:13:36 +08:00

前端的坑随着时间流逝越来越多，直至无法填满，然后重做或者开新产品线

throns

2020-06-29 22:16:39 +08:00 via iPhone

同是一名初级前端，刚开始工作的时候，面对一些陈年老坑的项目非常抵触，做着很痛苦，后来慢慢地调整了心态，一步步改造，自己忍耐度不断提高，抵触的情绪也消失了。个人觉得心态的调整非常重要，很多成长都需要自己去挖掘，和要好的同事多交流很重要！

linghutf

2020-06-29 23:33:00 +08:00 via Android

查问题确实费劲还不讨好，没什么产出。而且 case 多了也并不能累积经验，因为千奇百怪。头条后端也这样吗

daquandiao2

2020-06-30 06:12:17 +08:00 via Android

前端面试进去要算法吗？
大部分人没有涨薪？入职即巅峰？

mxT52CRuqR6o5

2020-06-30 07:32:23 +08:00 via Android

@azh7138m
安卓这边用户不愿意升级应用，强制升级可能造成用户流失，结果就导致开发要各种兼容旧版
Ios 你描述的那个问题感觉应该让 api 提供方解决

xwhxbg

2020-06-30 08:59:52 +08:00

2020 年中旬了，还没用 Typescript 真的是自己给自己找坑

wotemelon

2020-06-30 09:38:57 +08:00

@azh7138m 简直太真实了，现在代码充斥着各种 magic number

fhsan

2020-06-30 09:42:22 +08:00

@linghutf 头条目标十万员工，怎么都要有人填坑

030

2020-06-30 09:44:24 +08:00

@mxT52CRuqR6o5 不升级还不是自己作，越升级体验越差，国产应用不配自动更新

mxT52CRuqR6o5

2020-06-30 09:49:27 +08:00 via Android

@030 我指的是应用市场的问题，google play 和 app store 默认都会自动升级吧，而国内应用市场混乱导致升级不能保证

deepred

2020-06-30 10:07:33 +08:00

老哥很厉害了。我当初字节呆了 3 个月就跑了，可能当时心态崩了吧。

nianyu

2020-06-30 10:14:13 +08:00

不想当工具人，想实现自己的价值，就得自己有产品观念，把自己的东西做成产品，翻身做主人

azh7138m

2020-06-30 10:15:11 +08:00 via Android

@xwhxbg
> 2020 年中旬了，还没用 Typescript 真的是自己给自己找坑

匆忙重构后是 ts，但是重构前的主要流程，我都有写 jsdoc，出入参类型还是有的

19 年初离职的时候，我们项目代码有 1/3 是 ts （ 10w 行），应该算是个中型应用了
委实说，ts 并不能解决业务问题，只是用来降低协作成本与后期维护成本

但是我看全文，也没吐槽这个东西，老哥是怎么脑补出来的。。。

nuanyang

2020-06-30 10:38:30 +08:00

评论区一些老哥脑补过于严重，感觉到一点点恶意

1044523901

2020-06-30 11:00:08 +08:00

@throns 现在就不抵触陈年老项目了？

beizhedenglong

2020-06-30 11:07:45 +08:00

离职去哪了

serco

2020-06-30 11:27:49 +08:00

字节的一些工具真的烂到令人发指。。。巨量引擎日常 500，各种小 bug 更是多到数不过来。。严重影响我烧钱的心情🐶

xwhxbg

2020-06-30 12:18:40 +08:00

@azh7138m 因为你抱怨的所有问题都可以通过 Typescript+单元测试证明自己的服务没问题，而不是去 debug 后端，前后端分离以后因为后端有单测，rust 各种编译期检查，所以人家可以自信的说自己的 service 没问题，是前端 bug，你找出对方的 bug 是没用的，你得自证稳定性，不然出了问题你猜老板第一个 @谁？

rioshikelong121

2020-06-30 12:20:52 +08:00

bug 路由器？

azh7138m

2020-06-30 12:32:53 +08:00 via Android

@xwhxbg
> rust 各种编译期检查，所以人家可以自信的说自己的 service 没问题

这么自信啊，那 rust 时序问题坑到我是我的问题喽？ hyper 请求 HTTP/2 服务慢于 HTTP/1.1 也是我的问题喽？

前端代码没有问题，客户端出现问题，你就得兼容，用户不会管问题到底出在哪里，运营不会，你的老板也不会。

你要没有被上游坑过，或者没有阅读能力，可以不用强行回复。

royzxq

2020-06-30 12:36:46 +08:00

starling 那边 oncall 处理的也很快，SDK 也蛮好用的（就是有时候有点抽风发布了不能及时生效）

mxT52CRuqR6o5

2020-06-30 12:38:53 +08:00 via Android

@azh7138m 是指代码层面先发请求 a 再发请求 b，结果 http 层面请求 b 先发出去了吗？

azh7138m

2020-06-30 12:41:06 +08:00 via Android

@mxT52CRuqR6o5
是网络请求发不出去
后来 rust SDK 的同学处理了，只是遇到这类问题着实心累
我要来回看大量的日志，去找上游说明问题
运营还一个劲的问有没有进展，太难了

xwhxbg

2020-06-30 12:59:25 +08:00

@azh7138m 我做过 2 年前端，然后 3 年后端，js，ts，rust，node，golang 都写过，事实是老板不会管问题真的是谁的，他只 @最不自信的那个人，客户端有问题你应该据理力争让客户端修复，而非懒得跟他们计较，我原来做前端的时候调用 native 实现的地图 SDK，然后出了问题客户端说我调用 SDK 的时机不对，此时我就不会问时机是什么，而是督促客户端修复一个稳定的 SDK 出来。后端 bug 同理。
听你的语气感觉应该是个暴躁老哥了，我以前也以为技术最重要，那帮菜鸡不会修那我自己动手，然而客观事实是国内的公司主要是管理问题，如果你的上级不强硬，你得自己跟客户端后端甚至设计师去博弈，不然最终会发现设计师丢给你一个半成品要你自己切图，后端接口连他自己都没用 postman 测过，全靠前端承担所有义务和责任。

既然你觉得我是强行评论，我觉得你可以 block 甚至 report 我，但是客观事实不以情感为转移。

seki

2020-06-30 13:17:22 +08:00

不知道是不是字节内部的文化和流程有特殊性，运营肯定优先找到前端这没问题。如果有时间当然可以到处查代码，把最终问题都找出来，但是作为前端，当确认不是自己的问题的时候，应该可以把 case 转给其它团队的吧。不应该都挂在你的头上

ai277014717

2020-06-30 13:26:22 +08:00

@azh7138m 这些都是常规操作。远离混合开发就好了。

azh7138m

2020-06-30 13:32:07 +08:00 via Android

@xwhxbg
> 客户端有问题你应该据理力争让客户端修复

客户端要修复和你要兼容并不冲突，已经发上线的版本，你不可能说不兼容就不兼容

除非真是大问题，否则一般不会是我老板来 @我，正常都是运营 /Pre sale 同事来 oncall

我们开发要接 oncall，用户报过来的是问题，你要修复

我并不暴躁，PM 甚至觉得我有耐心，能和用户一遍一遍解释问题（🐶

后端都是自己团队的，问题也很少出，出了修的也很快，上游都是你依赖的其他团队

非重要的 bug 都得前端自己兼容，修复有可能会到下个双月

我没有觉得上游蔡，只是频繁的排查客户端问题让我心累

为什么不让客户端自己去排查？你没有石锤的证据，推都推不动

比如客户端有个很严重问题，来回扯皮了半年，感觉终于要开始着手修复了

我要是让运营告诉用户让他们等半年，估计我就先被打死了

@seki
to B 业务，现在都是用 Data 反馈平台，过来基本都是 oncall，很少有 /会用 jira