一名刚入行的开发者在 GitHub 上提交了第一个 PR，第二天收到了 47 条 review 意见，其中 12 条是缩进问题，15 条是变量命名不规范，剩下 20 条全是逻辑分支没覆盖边界情况。这不是个例，而是新手最容易踩入的陷阱：把精力全铺在“写代码”上，却忽略了“写可维护的代码”才是生存关键。

别先学框架，先拆解“最小可运行系统”

大多数新手的第一反应是打开 Vue 或 React 教程，跟着敲一个 todo list。但你会发现自己卡在 webpack 配置、路由钩子、状态管理这些外围工具上，核心的逻辑反而没练到。正确做法是：先用手头的语言写一个无依赖的“文件结构预览器”——只读本地目录，生成树形图，控制台输出。这个场景强制你处理递归、路径拼接、权限判断、字符编码。等这个程序跑通了，再思考怎么把它套进框架里。我见过一个转行的电气工程师，用 Python 写了个简单的串口日志分析器，跑了三个月，后来只花两天就把它包装成了 Flask 应用。核心能力早就在写无依赖版本时练熟了。

调试比写代码更能拉开差距

同一个 bug，新手会花 2 小时在代码里加 print 语句，反复重启服务。有经验的人会先打开浏览器的 Network 面板，看请求返回了 500 还是 400，然后直接看后端日志的堆栈跟踪。一个真实案例：某团队新人碰到接口超时，盲目地给数据库加索引、加缓存，折腾了一下午。老员工过来看了一眼，发现是 Nginx 的 worker_connections 设成了默认 512，并发一高就排队。他用一条 curl 命令复现了问题，再用 `ulimit -n` 确认了系统限制，全程不到 10 分钟。建议你从一开始就养成习惯：遇到问题先想“用什么工具可以最快缩小范围”，而不是“哪段代码可能错了”。

用“代码考古”代替“从头重写”

很多新手接手老项目时，第一反应是“这代码太烂了，我要重写”。我见过一个实习生花了三周重写一个报表模块，结果上线第一天就发现遗漏了对旧数据格式的兼容处理，导致三个月的历史报表全变空白。更好的做法是：打开 git log，用 `git blame` 查每一行代码的最后修改人、提交时间和关联的 issue 号。然后去读这些 commit 的 message，了解当初为什么这么写。你会发现很多看起来“反直觉”的代码，背后其实是对某个特定 bug 的修补。比如一个看似多余的 if 判断，可能是为了兼容某个已经废弃的 API 响应格式。理解这些历史约束后，你才有资格判断：哪些逻辑现在依然必要，哪些可以清理。

• 误区一：花大量时间选“最佳语言/框架”——其实选你当前项目里最常见、文档最全的就行。真到了需要换技术栈的时候，你已经具备迁移判断力了。
• 误区二：代码写完就跑，不看编译警告——TypeScript 的 strict 模式、ESLint 的 error 级别警告，每一个都是在帮你提前堵住运行时可能爆炸的坑。
• 误区三：遇到报错直接复制粘贴到搜索引擎——先自己读报错信息前两行，确认是“语法错误”“类型错误”还是“网络异常”。能准确描述问题，你的搜索效率会翻倍。