周三晚上十一点，一个程序员删掉了自己写了三个月的代码。
不是功能跑不通，恰恰相反——项目架构太完美了。微服务拆分、Docker编排、CI/CD流水线，还有为"未来百万用户"准备的全球分布式部署方案。唯一的问题是：核心功能还没写完，人已经累垮了。
这不是孤例。开发者圈子里有个黑色幽默：最精致的代码往往躺在GitHub的私人仓库里，永远等不到第一次commit之外的访客。
01 周末创意，企业级配置
问题出在起点就错了。我们把一个周末黑客松的灵感，当成拿了风投的创业项目来搞。
看到简单的需求，大脑自动跳转：全栈架构、微服务、Docker Compose、CI/CD管道、全球分布式部署。配置文件的行数比业务代码还多，还没见到用户，精力先耗尽。
作者举了个扎心的对比。一个简单的"Hello World"接口，实际需要的可能只是：
function handler(req, res) { res.status(200).send('Hello, world!'); }
但我们有时为了"未来可扩展性"，会搭出一整个服务类：
class HelloWorldService { constructor(logger, config) { /* ... */ } async getGreeting(name = 'world') { /* ... */ } }
一个能跑，另一个在业务逻辑还没动笔之前，就已经是个完整项目了。
02 复杂性的三个入口
技术新玩具的诱惑。想搭个简单博客？等等，"这正是学SvelteKit配合无服务器函数、再用AWS Lambda搭GraphQL API的完美借口"。内容还没上线，先迷失在配置文件里。
为"未来"过度设计。个人任务管理器不需要多租户认证系统，简单数据可视化不需要完整分析仪表盘。核心功能没验证，先解决不存在的问题。
"完美"陷阱。"还不够完美，不能发布。"真相是：永远没有完美。一个不完美但能用的产品，比永远在调试的"完美"项目强一百倍。项目只有先存在，才谈得上扩展。
03 简单不是简陋，是有效
简单意味着剥离一切不直接服务于最初核心目标的东西。用最顺手的工具，先做出来，先发出去。迭代是后面的事。
作者的身份是自由职业网站开发者。他说这个教训对客户项目同样适用：客户要的是解决方案，不是过度 engineered 的杰作。
核心原则只有一条：能发布的最小可用产品，比困在开发地狱里的功能丰富项目，价值无限大。做最小、能交付价值的东西。
如果你也有朋友卡在"教程地狱"里——看了无数课，写了无数配置，就是没发布过任何东西——把这篇转给他们。
热门跟贴