写给刚开始写代码的自己

前几天有个朋友刚转行做开发，问我有什么建议。我零零散散说了些，事后想想可以整理得更清楚。

写下来，算是给当年的自己。

一、把"看懂"和"会写"分开

最开始学编程的时候，看教程什么都懂，自己写就卡住。当时以为是自己笨。

后来明白这是正常的。看懂是被动接收，会写是主动构造，中间隔着一道墙。 拆掉这道墙的唯一办法是自己动手写，而且写的时候不看教程。

现在我学新东西的流程是：看一遍文档，然后关掉文档自己写一遍。写不出来再回去看，但只看看不出来的那部分。

这个"自己写"的环节，比看十遍教程有用。

二、错误信息要读到底

以前看到报错第一反应是复制去搜索。搜到答案贴上，问题解决了，但不知道为什么。

现在的习惯是先读完错误信息：

• 出错的文件和行号
• 具体是什么错（类型不对？变量未定义？文件不存在？）
• 调用栈里哪一层是我的代码

大概七成的错误读完信息就能想明白。剩下三成再搜，但搜的时候也能问出更准确的问题。

"读错误信息"是个可以练的技能。 而且越往后越重要，因为越复杂的系统，报错信息里包含的线索越多。

三、先让它跑起来，再让它变好

我以前写代码喜欢一次写对。想清楚了每一个边界情况，然后一口气写完。

问题是：想得越多，开始得越晚。而且大部分"想清楚"的边界情况，实际上根本不会发生。

现在的做法是先写一个"能跑就行"的版本。

比如要写数据同步：

# 第一步：最朴素的方式，能跑通就行
for row in source:
    target.save(row)

跑通了，确认基本逻辑对，再考虑：

• 批量写入（性能）
• 失败重试（健壮性）
• 断点续传（大批量）
• 并发（提速）

每一步都有可运行的版本，而不是先在脑子里设计完整再动手。

这个方式还有个好处：早发现"需求理解错了"。如果花两周设计再开始写，发现理解错了就白费；如果先写个粗糙版本给人看，十分钟就知道方向对不对。

四、代码是写给人看的

我用了很久才接受这件事。

刚工作时，我评判代码的标准是"能不能跑"。后来加上"跑得快不快"。再后来才是"别人能不能看懂"。

现在我优先级最高的反而是可读性。因为：

• 代码被阅读的次数远多于被编写的次数
• 一个读不懂的优化，三个月后自己也不敢改
• 团队协作下，看不懂就等于不能用

具体怎么做：

名字要准。 processData() 不如 calculateMonthlyRevenue()。多打几个字，省下别人十分钟。

函数要短。 一个函数做一件事。如果一个函数需要"并且"来描述它做什么，那就该拆。

注释写"为什么"，不写"是什么"。 // 循环用户列表 没有意义；// 这里要倒序，因为后面的逻辑依赖最新的在前 有价值。

五、学会说"我不知道"

这条我花了最久。

刚开始工作时，怕被人觉得水平不行，遇到不懂的会含糊过去，或者凭猜测给个答案。

结果是有一次猜错了，导致同事基于我的错误信息做了一天的无用功。那件事很尴尬。

后来我改了：不知道就说不知道，然后说"我去查一下"或者"我不确定，可能是 X，我们验证一下"。

出乎意料的是，没人因此觉得我水平差。反而因为我给的答案可信度高了，大家更愿意问我。

"我不确定"比一个错误的肯定答案有价值得多。

六、把时间花在基础上

我有一段热衷于学各种框架和工具。React、Vue、Django、Laravel、Spring 都摸过一遍。

但基础的东西——数据结构、算法、操作系统、网络、数据库原理——一直是短板。

结果是：遇到性能问题不知道怎么分析，遇到并发问题只能靠搜，遇到奇怪的 bug 看不懂底层原因。

真正的分水岭出现在我开始读《深入理解计算机系统》和看数据库的实现原理之后。很多"玄学问题"变得可以推理了。

框架会过时，基础不会。

七、接受"写不完"

以前总觉得项目做完了就轻松了。实际上没有"做完"这回事。

需求会变、依赖会升级、服务器会换、流量会涨。维护是常态，不是例外。

接受这一点之后，心态好很多：

• 不用追求"一次写完美"，反正要改
• 不用做完所有功能才上线，可以慢慢迭代
• 不用因为"还有 TODO"焦虑，TODO 本来就不会清零

八、记录比记忆可靠

我记性一般。以前靠记性，经常出现"这个坑我好像踩过但忘了怎么解决的"。

现在会写：

• 踩过的坑和解决办法
• 一个决策的来龙去脉（为什么选 A 不选 B）
• 排查问题的过程（哪怕最后没解决）
• 看到的好文章和自己的理解

不用写得多正式，我自己用的就是简单的 Markdown 文件。

写下来这个动作本身就有价值——它强迫你把模糊的理解整理成清楚的表述。很多时候写的过程中就想明白了。

九、关于"天赋"

这个可能是最想对当年的自己说的。

我曾经因为"别人好像很快就懂了，我要好久"而怀疑自己不适合做这行。

后来发现两点：

一、别人没那么快。 你看到的是他学会之后的表现，没看到他卡住的时候。

二、这东西确实有快慢，但差别没想象中大。 而且持续性比初始速度重要。我见过很多上手快的人三五年后停在一个水平，也见过上手慢但一直在深挖的人后来居上。

如果一定要选一个特质，我选"能持续地投入时间"，而不是"聪明"。

十、最后一条

做点能给别人用的东西。

学的时候容易陷在"学"本身。但真正让我进步最快的，是做一个真的有人在用的东西。

因为有人用，所以：

• 要考虑他没按你预期操作的情况
• 要处理你没想过的数据
• 要把错误信息写清楚（不然他看不懂）
• 要真的把功能做完（不然他不用）

这些都逼着你把东西做扎实。玩具项目可以糊弄，有人用的项目不行。

最后

这些话如果传回去给当年的自己，他大概会觉得"这些我都知道啊"。

知道和做到之间还是有距离的。而且有些事大概只能自己踩过才懂。

不过还是写下来了。万一有点用呢。