我觉得公司和岗位的重要性各占一半吧，在大厂做边缘业务，和小厂做核心业务，价值其实是一样的。更多还是看个人能力可不可复制，业务和岗位有没有上升空间，没必要死磕大厂。 小公司的技术团队一般也就百来号人，开几次全员大会，公司什么情况、接下来要做什么，基本就摸清了。平时吃饭闲聊，也能知道行业里在玩什么。想知道别的团队在干嘛，搬个椅子去聊聊天就行，组织扁平得很。趁着这个机会前后端都折腾一遍，慢慢就能找到自己真正感兴趣的方向。 技术选型上，小公司喜欢追新，能买第三方的绝不自己造。但问题也明显，基础设施不完善，经常东拼西凑用开源方案凑合，规范不统一，有时候感觉就是在“把东西弄出来先跑起来”。工作标准也相对宽...

绷不住了

给时间时间 终会梦想成真的🥺那就努力努力再努力🤲

网上类似的源码长文不少，我最近也在写 React 源码。作者往往写得尽兴、覆盖面也广，读者却不一定对得上自己的节奏：你想抠的那一点未必落在文章的主线上，而仓库一直在演进，成稿稍一搁置，对照现版就容易对不上号。也正因如此，很多同学更倾向于亲自读源码。带着问题找答案，节奏和技术栈都更贴自己。这篇想分享的是读大型前端开源项目（例如 React、Vue、Webpack、Babel）源码时怎么切入、怎么少迷路。目标很简单：授人以渔，让你在遇到新机制、底层实现或 Bug 时，能自己钻进去看清楚。为什么读源码要先有问题读之前先想清楚：为什么要打开仓库？我的看法是，首要目的是解决实际问题。没有目标地&quot...