如何维护一个小项目

引言

说实话，做项目最爽的时刻是什么？是功能完成、上线跑通的那一瞬间对吧？但紧接着，你会发现一个残酷的事实——项目上线才是真正的开始。之前写的那堆代码，就像刚买的新车，开久了总会出问题：小bug冒出来、依赖过期了、想加新功能却发现根本不敢改老代码……

我这些年陆陆续续维护过不少小项目，有开源的玩具项目，也有公司内部的小工具。今天想跟你们聊聊，我是怎么处理这些"甜蜜的负担"的。不是什么高大上的理论，就是一些实打实的经验教训，希望能帮到正在维护小项目的你。

规范先行，别给自己挖坑

很多人觉得，小项目嘛，写那么讲究干嘛，自己能看懂就行了。我以前也这么想的，结果呢？三个月后再看自己的代码，完全想不通当时为什么要这么写，甚至怀疑是不是喝多了写的。

所以啊，哪怕项目再小，基本的代码规范还是得有的。我现在开新项目，第一件事就是定好编码规范，用ESLint、Prettier这类工具把格式统一起来。你不需要搞得太复杂，团队几个人坐下来花半小时定几条核心规则就够了。

// .eslintrc.js 示例
module.exports = {
extends: ['eslint:recommended'],
rules: {
'no-unused-vars': 'warn',
'no-console': 'off',
indent: ['error', 2]
}
};

文档这件事吧，很多人觉得麻烦，但我发现一个取巧的办法——与其专门写文档，不如让代码本身就是文档。变量名起清楚一点，函数职责单一一点，关键逻辑写点注释，真的不需要长篇大论。我现在维护的项目，README里就三样东西：怎么安装、怎么运行、常见问题。简单明了，比那些几十页的文档实用多了。

自动化才是亲爹

手动测试有多痛苦，做过的人都懂。每次发版前要手动跑一遍测试用例，累不说，还容易漏。我现在是坚决贯彻"能自动化的绝不手动"原则。

单元测试这件事吧，我觉得不用追求100%覆盖率，但核心业务逻辑一定得覆盖到。比如用户登录、数据校验、支付流程这些，写个测试用例安心很多。你可以用Jest、Mocha这些工具，都很成熟了。

// 用Jest写个简单的测试
describe('calculatePrice', () => {
it('应该正确计算折扣', () => {
expect(calculatePrice(100, 0.8)).toBe(80);
});
  
it('应该在数量为0时返回0', () => {
expect(calculatePrice(0, 1)).toBe(0);
});
});

CI/CD这个事儿，别被名字吓到了，不是一定要用Jenkins、GitHub Actions那种大家伙。小项目用GitHub Actions的免费额度完全够了，每次push代码自动跑测试、跑lint，通过了才能合并到主分支。这东西一旦配置好，后面省心太多了。

依赖管理是个技术活

你们有没有遇到过这种情况：项目跑得好好的，某天突然报错，一查发现是某个依赖包版本不兼容了。这种事情发生一两次，你就知道依赖管理有多重要了。

我的做法是，锁死版本号，别用那些^1.2.3之类的模糊版本。package-lock.json或者yarn.lock文件一定要提交到仓库，这样任何人clone下来安装的依赖都是一样的。

还有一点，定期更新依赖。别等到出问题了才想起来更新，那会儿往往就是一堆breaking changes等着你。我一般每个月会花半小时看看依赖有没有安全更新，用npm audit跑一下，有漏洞及时补。

# 定期检查依赖
npm outdated
npm audit

有些依赖长时间没人维护了，该换就得换，别恋旧。我之前有个项目用的一个ORM，官方两年没更新了，出了bug都没人修，最后逼得我自己fork了一份改。回头想想，早换掉能省不少事儿。

监控和日志，不能少

项目跑起来了，你就得知道它运行得怎么样。小项目虽然没有专门运维团队，但基础的监控还是要有。

日志这块，我建议统一用一个日志框架，别到处console.log。现在很多日志库支持不同级别、输出到不同地方、还能自动切割日志文件，用起来很方便。

const logger = require('pino')({ level: 'info' });

logger.info('用户登录成功', { userId: 123 });
logger.error('订单创建失败', { error: err.message });

错误监控可以用Sentry这类工具，免费版对小项目完全够用。它能自动收集报错信息，还能看到具体的堆栈轨迹，比用户给你发截图强一百倍。我现在项目出了错，Sentry第一时间通知，比我自己发现还快。

适度重构，别硬撑

代码写久了，总会有一些历史包袱。什么时候该重构，什么时候该凑合，这个度挺难把握的。

我的经验是：如果某个模块你改起来特别痛苦，每次都要花很长时间理解逻辑，那就该重构了。但重构要慢慢来，别想着一口气把所有问题都解决了。先把最影响开发效率的部分改了，剩下的问题以后再说。

还有一个原则叫"三次原则"：同样类型的代码出现三次，就该考虑抽象了。别等到写了十处相似的代码才想起来提取函数，那时候改起来动静太大，风险也高。

总结

好啦，说了这么多，其实维护小项目最重要的就是一个词——可持续。别搞得太复杂把自己累死，也别太随意以后没法收拾。找到适合自己的节奏最重要。

我的建议就三点：规范先定、自动化到位、监控跟上。剩下的就是保持好习惯，定期维护，别等出了问题才想起来补救。

项目就像养宠物，既然养了就得负责到底嘛。希望这些经验对你有帮助，有什么问题欢迎评论区聊聊。