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