开发心得

做过的项目多了，慢慢攒下几条自己信得过的习惯。都不是什么高深理论，全是被现实教训出来的。它们的共同点是：每一条刚开始做的时候都觉得很麻烦，做久了才发现省下的是大麻烦。这篇按"一个东西从想法到长期在用"的顺序来写，你能看到每条习惯是在哪个阶段救的命。

一、动手之前：先把"做成什么样"写下来

这一条看着像废话，但它是省时间最多的一步。我以前的习惯是"想个大概就开干"，结果做到一半发现某个关键地方自己都没想明白，于是前面的活儿要重新拆。

现在我改成先用几行字回答三个问题，写在最前面：

• 它做完之后，我要用它干哪一件具体的事？不是"做一个管理系统"，而是"我要能一眼看到上周哪些活没干完"。
• 哪一部分是这个东西的核心，哪一部分可以先没有？把功能按"没有它就不成立"和"有更好、没有也行"分成两堆。
• 什么情况下我会觉得它是失败的？这个问题反着问特别有用——它逼你说出真实的标准，而不是模糊的"好用"。

这三句话通常十分钟就能写完，但它们会把后面几周的方向定下来。更重要的是，写的过程里你会自己发现"原来我还没想清楚"。

二、第一步：先有能跑的最小版本

别一上来就想着做全。先做一个最小、能跑、能看见的东西，哪怕功能少得可怜。它的价值不在功能，在于它给了你一个"地基"——后面所有东西都是往它上面加的。

这个循环有两个隐含要求，都容易被违反：

• 每一圈要小。如果一圈要跑一周，那你一周才能得到一次反馈，方向错了要一周才知道。把它拆到一天跑一圈，试错速度就快七倍。
• 每一圈都要真的跑起来。"我写了一大堆，等全部写完再一起测"——这是最危险的模式。因为一旦出问题，你面对的是一个巨大而模糊的失败，不知道哪个部分出的错。

三、第二步：让它经得起别人用

能跑了之后，会有一个危险的错觉：以为"能跑"就等于"做完了"。实际上从"我自己能用"到"别人也能用"，中间还隔着好几道坎。我把这几道坎总结成三件事：

1. 日志：出问题时别靠猜

程序出问题的时候，人的第一反应通常是"我猜是哪错了"。这个猜测的准确率非常低，而且一猜就沉迷，花两小时在错误的方向上。正确反应应该是：让它把过程打印出来看看。

# 关键节点各留一行，出问题时一眼看出卡在哪
print("收到输入:", str(data)[:80])
print("清洗后条数:", len(cleaned))
print("处理结果:", result)
print("已写入:", save_path)

我的习惯是：凡是"跨出去"的动作，前后各记一笔。读了文件、发了一个请求、写了一次库、返回了一个结果，每个动作都留一行。这样事后排错不用推理，直接看日志就行。

2. 配置与代码分开

会变的东西别写死在代码里。路径、地址、开关、阈值、密钥——全部放到外面的配置文件里。这样换台机器、换批数据，改配置就行，不用动代码。

这条我一开始觉得是"过度设计"，直到有一次要把一个脚本从自己的电脑挪到服务器上，发现里面有十几处硬编码的路径要改，改漏一处就报错。那次之后我就老实了。

3. 把可能的意外接住

自己用的时候，你大概知道会输入什么。别人用的时候，什么都会发生：路径不存在、文件被占用、编码不是 UTF-8、网络中途断了。这些不能靠"应该不会发生"来规避，只能靠提前处理。

我的做法不复杂：把单个条目的处理包在错误捕获里，失败了就记下来、跳过、继续处理下一个。最后统一汇报"成功了几个、跳过了几个、为什么跳过"。核心原则是一条坏数据不该毁掉整批任务。

四、第三步：上线之后才是真正开始

"上线"这个词容易给人一种"完成了"的错觉。实际上从这一刻起，你才开始接触到真实的使用情况：真实的输入、真实的网络、真实的并发、真实的人。

这个阶段有几件事我特别在意：

• 第一天：先确认基本盘。能不能访问、有没有报错、资源占用正常不正常。这几样确认完再谈别的，别一上线就先啃功能细节。
• 第一周：收集真实反馈。这段时间暴露出来的问题，几乎都是设计时想不到的。所以反馈越具体越好——不是"不好用"，而是"我点了那个按钮之后等了很久，以为没反应"。
• 第一个月：观察资源趋势。磁盘在涨还是稳、内存有没有缓慢泄漏、高峰时段是什么时候。这类问题不会让你当场崩溃，但会在某天突然把你打倒。
• 之后：定期回头看一眼。没有变化的东西也要看，因为"一直没问题"和"已经悄悄坏了但你不知道"，表面是完全一样的。

五、几条通用的保命习惯

给自己留回滚的余地

动重要数据或配置之前，先备份、先留一版能退回的状态。关键在于对"重要"的定义要放宽一点——只要你事后可能会后悔，那它就是重要。复制一份的成本几乎为零，回不去的成本可能是一整天。

真正的麻烦通常不是"改错了"，而是"改完发现不对，却回不去了"。留后路不是保守，是专业。

每次只改一处

我发现新手和老手有一个很明显的区别：新手喜欢一次改好几处然后跑一次；老手每次只改一处，改完立刻跑。一次改三处，出现问题时你不知道是哪一处导致的，于是只能靠猜——而猜出来的结论往往是错的，会把你引向更深的坑。

文档写给三个月后的自己

你以为记得住的细节，三个月后一定忘。当时为什么这么写、这个参数是干嘛的、这条分支是处理哪种特殊情况的——顺手记两笔。不需要写得多正式，写在代码旁边一行注释就够。

这条的收益我感受特别深：三个月后回来看自己写的东西，如果能五分钟就改得动，说明当时那两行注释帮了大忙。

先让它对，再让它快

不要一开始就优化性能。绝大多数性能问题，要么根本不影响实际使用，要么出在你完全没预料到的那一行上。正确顺序是：先做对、先能用，等真的慢了——而且是能看见它慢——再去量、去定位、去改。