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