小项目里的工程取舍：10 年后我还在坚持的几件事

做过的项目里，小单子反而最考验工程能力。大项目有预算、有时间、有架构组；一个两三周交付的小站、一个小程序，预算往往只够你做对三件事。

所以我给自己的规矩是：先把三件事做对，剩下的都可以妥协。

第一件：数据模型别急着设计

我现在的习惯是先上线，再补抽象。小项目的需求变化快，过早设计出来的模型，九成会在第三周推倒重来。真正要克制的是顺手加的字段——那些现在用不上、但我觉得将来会用的。

代价是早期要接受一段难看的代码。但难看的代码能改，错误的抽象要推翻重来。

这是最容易被砍掉、也最不该被砍的部分。需求评审的时候没有人会说「我要错误处理」，但线上出问题时，没人能从一句「出错了」里定位到任何东西。

我的底线很简单：每个对外接口都能查到请求参数、耗时和错误原因；每个异步任务都能查到它卡在哪一步。这两件事做好，排查问题的时间能差出十倍。

不管是官网还是小程序，交付的标准只有一个：拿到源码的人，不用问我要任何东西，就能把它在本地跑起来、部署上去。

这意味着要写清楚环境变量、启动命令、依赖版本，也要写清楚当初为什么选这个技术栈。三年后你自己回来改的时候，最怕的就是当初为什么这么选已经没人记得。

小项目里最容易犯的错，是顺手把不相关的东西也做了。做得多不等于做得好，尤其当你手上同时有好几个项目的时候。

我现在每个项目开工前会先写一句话：这个项目做成之后，我最希望别人记住的是哪一点。写不出来，说明需求还没想清楚，那就先别动手。

这几年我做过的项目类型很多，技术栈换过好几轮，但上面这几条一直没变。它们不新鲜，也不聪明，但真的能决定一个项目是交付了，还是烂尾了。