写了 10 年代码，我才发现最该学的其实是…
很长一段时间，我以为成为“更优秀的开发者”就是学更多工具。 更多框架、更多库、更多教程。如果我不持续升级技术栈，我就会感觉自己在落后。 所以我不停地切换，尝试新东西…… 结果呢？我并没有真正进步。 我花了很长时间才明白这个简单的道理： 成长并非来自做更多的事情…… 而是来自对正确的事情理解得更透彻。 你不能跳过 HTML、CSS 和 JavaScript，指望框架能带你一路顺风顺水。 如果你的基础薄弱： 扎实的基础可以消除你之后的大部分困惑。 很多开发者在了解开发环境之前就开始使用框架。 但所有功能仍然在浏览器中运行。 请求、渲染、缓存、DOM 更新……这一切都在你的代码底层进行。 如果你不理解这一层，框架就会感觉像魔法而不是工具。 即使你不是每天刷 LeetCode，你仍然需要结构化思维。 你不需要记住所有东西，但应该理解这些模式： 这种思维方式无处不在，不仅仅出现在面试中。 这就像编写可运行的代码和编写可扩展的代码之间的区别。 框架不是魔法。 了解它们实际的工作内容： 一旦你理解了“为什么”,“怎么做”就变得简单了。 网上很多开发建议都是正确的……但只在正确的上下文中。 在个人项目中有效的，在生产环境可能失败。在创业公司有效的，在企业系统中可能崩溃。 不要问“这个好吗？” 要问：“这个什么时候好？” 不要只是实现需求。 要理解： 这就是开发者和工程师的区别。 大多数人认为 TypeScript 只是添加类型。 其实不是。 它讲述的是： 一旦你习惯了，纯 JavaScript 就会让你觉得有风险。 如果你使用 Next.js，要深入了解，不只是看懂文件夹结构。 理解： 否则，你的应用能跑……但在生产环境中可能会出现不可预测的行为。 工具使用不当会浪费大量时间。 掌握： 这些工具每天都在使用。 这里的小改进累积起来的速度比你想象的要快得多。 大型任务让人感到压力巨大。 但它们中的大多数只是许多小问题的组合。 将它们分成： 这项任务变得容易多了。 你也会更快地看到进步。 一次解决一个问题，事情就会开始好转。 只要理解代码的功能，复制代码是没问题的。 问题出在盲目复制上。 后来，当出现 bug 时： 这就是为什么小 bug 会演变成漫长的调试过程。 写出巧妙的代码会让人感觉很好。 但之后，它就变得难以阅读、调试和修改。 大多数代码被阅读的次数比编写的次数多，因此从长远来看，可读性总是更重要的。 巧妙的代码能让人眼前一亮，而易读的代码则能让人受益终生。 一个常见错误是在完全理解问题之前就尝试优化。 先让它工作。 然后让它清晰。 然后只在真正重要时才优化。 过早优化增加了复杂性却没有价值。 几天后回来看你的代码。 如果它让你困惑……那就是反馈。 清晰的代码应该无需费力就能理解。 你不需要记住所有东西。 这项技能不是记忆，而是导航。 你需要知道： 这才是经验的真实面貌。 大多数 bug 并不复杂。 那只是你不知不觉中对自己撒的谎。 调试的过程就是不断证明自己是错的，直到最终回归现实。 看教程很容易感觉高效，因为看的时候一切都说得通。 但真正的理解只发生在你独自面对空白屏幕尝试构建东西时。 如果你从不离开教程，你永远学不会思考。 所以关掉视频，自己动手试试，你肯定会遇到问题卡住，那就是成长的地方。 强行解决问题会让人感觉很有成就感。 但暂时离开往往能更快地解决问题。 不用担心，即使你停止盯着它看，你的大脑仍然会继续运转。 如果你已经卡住几个小时，不要再想了。 经验证明，再往下也很少带来突破，通常只会带来挫败感。 大多数开发者都乐意帮忙的，前提是你已经尝试自己解决问题了。 谁也帮不了你解决“它怎么不起作用”这种模糊的问题。 但他们可以帮忙做这件事： 好的问题不仅能更快地得到答案，还能迫使你更深入地理解问题。 写代码只是开发者工作的一部分。 另一部分是： 在实际工作中，沟通问题比技术问题更容易引发问题。 写代码只是工作的一半，解释它是另一半。 你需要能够描述你在做什么、为什么这样做、存在什么权衡取舍。 这体现在： 清晰的沟通能够防止误解，否则会变成 bug 或浪费时间。 如果你能把复杂的概念用简单易懂的方式表达出来，你在任何团队中都会立刻变得更有价值。 在发布前试图让事情完美通常会拖慢整个流程。 比起本地一个完美的版本，从生产环境中运行的版本中你能学到更多东西。 即使你不是设计师，你仍然可以塑造用户体验。 这些细节比大多数开发者想象的更重要。 因为用户看不到你的代码。 但他们会感觉到。 如果你与你所创造的东西缺乏联系，那么光有技术是不够的。 人们会注意到你真正关心的是产品，而不仅仅是代码。 你不需要表现得过于兴奋，但你需要表现出解决问题的兴趣，而不仅仅是完成任务。 这种态度会让你更可靠、更值得信赖，也更有可能获得更好的机会。 大多数时候，热情会悄然转化为职业发展。 你不需要独自解决所有问题。 一位好的导师可以指出真正重要的事情，帮你节省数月的试错时间。 他们不会给你所有问题的答案，但他们可以帮助你避免一些愚蠢的弯路。 有时是公司里的高级开发人员，有时是网上你很欣赏的人。 向那些已经达到你想达到的高度的人学习。 开源软件能教会你教程永远无法教会你的东西。 你将面对真实的代码库、真实的限制条件，以及真实的人员对你的工作进行审查。 一开始可能会觉得有点吓人，但这正是关键所在。 从小处着手： 随着时间的推移，你会逐渐了解大型系统的实际结构，以及在你自身圈子之外，协作是如何真正运作的。 当你觉得自己“弄明白了”的那一刻，你的速度就开始放慢了。 工具会改变，模式会演变，去年行之有效的方法今天可能就不够用了。 你不需要追逐每一个潮流，但你应该保持灵活。 要勇于质疑自己的习惯，并在出现更好的方法时尝试这些方法。 教学是提升自身理解力最快的方法之一。 当你向别人解释概念时，你会立刻发现自己知识上的不足。 你不需要成为专家才能提供帮助；只要稍微了解一些就足够了。 它迫使你更清晰地思考，同时也让整个生态系统变得更好。 许多优秀的工作之所以不为人知，仅仅是因为没有人谈论它们。 发布你的项目、经验教训或小成就，有助于你随着时间的推移建立声誉。 你不需要“爆红”，你只需要坚持不懈。 人们开始记住你的名字，而机会往往就来自于这种悄然的曝光。 大多数增长并非来自重大突破。 它源于持续不断的小改进。 你不需要了解所有事情， 只需要再每次建造时都多花一点心思。 这就是普通代码如何变得优秀的过程。 也是优秀开发者成长为卓越开发者的过程。 我是冴羽，10 年笔耕不辍，专注前端领域，更新了 10+ 系列、300+ 篇原创技术文章，翻译过 Svelte、Solid.js、TypeScript 文档，著有小册《Next.js 开发指南》、《Svelte 开发指南》、《Astro 实战指南》。 欢迎围观我的“网页版朋友圈“，关注我的公众号：冴羽（或搜索 yayujs），每天分享前端知识、AI 干货。
1. 掌握基础知识
2. 理解浏览器做了什么
3. 提升数据结构和算法思维
4. 理解框架而不是死记硬背它们
5. 上下文比建议更重要
6. 理解业务
7. TypeScript 不只是关于类型
8. Next.js 不只是“更简单的 React”
9. 正确使用工具
10. 把问题拆成小块
11. 不要复制你解释不了的代码
12. 优先选择可读性高的代码，而不是设计巧妙的代码
13. 不要过早优化
14. 像陌生人一样阅读自己的代码
15. 搜索是一项真正的技能
16. 调试 = 消除错误假设
17. 创造要大于消费
18. 卡住时休息一下
19. 卡住太久就寻求帮助
20. 提出更好的问题
21. 沟通是工作的一部分
22. 学会清晰地解释你的想法
23. 完成比完美更重要
24. 始终考虑用户体验
25. 对工作表现出热情
26. 寻找导师
27. 为开源做贡献
28. 保持开放的心态去学习新事物
29. 指导年轻开发者
30. 在社交媒体上分享你的作品
最后