以前我在大厂里头，那是真的折腾。我们那项目，名字听着高大上，代码堆得跟山一样高，文档写得比字典还厚。天天讲究架构要多么稳固，系统要多么万能。结果？我们砸进去几千万，熬了两年多，上线的时候，系统比蜗牛还慢，稍微改动一点点东西，整个团队就要跟着连轴转好几天。
我那时候天天陷在里面，觉得这就是常态，不复杂就不高级。后来出事了。一个关键模块在发布前夜直接崩掉了，查了三天三夜，才发现是底层一个不起眼的组件版本冲突。老板气疯了，项目直接被砍，我们整个小组都被打散重组。我成了背锅侠之一，直接被调到个鸟不拉屎的边缘部门，负责一个没人愿意碰的遗留系统维护。那段时间，我可真是灰心透顶。
领导让我把这个遗留系统跑起来，但预算只有零头，时间给得极紧。我当时就悟了：搞什么长久稳定，搞什么万能架构，都是虚的。能快速解决问题，活下去才是王道。我当时就决定，一切推倒重来，就用最快的、最简单的路子来。我把它叫做“蜉蝣君”实践。蜉蝣嘛生命周期短，但是它能飞，能快速完成使命。我就是要让我的解决方案，快速地跑起来，干完活就拉倒，不需要考虑什么十年后的扩展性。
我是怎么实践“蜉蝣君”的？
在接手那个烂摊子的时候，我第一件事就是坐下来，把所有流程都重新梳理了一遍，我发现里面有百分之八十的功能，根本就是给那些“如果”和“万一”准备的，实际使用率极低，但是却占用了我们百分之八十的开发和维护时间。
- 第一步，果断地“扔”：我把所有华而不实的中间件，那些动不动就要搭集群，要写配置文件的东西，全他妈扔掉了。我只留了最简单的，能单机跑起来的工具。数据存储，我选择了轻量级的嵌入式数据库，配置起来不到十分钟。以前的项目，光是环境搭建就要耗费两天。现在我半小时就能搭建完毕，立刻就能开始干活。
- 第二步，目标要“专”：我逼着自己，一个功能只对应一个服务，只解决一个问题。之前我们是把十个功能塞到一个大包里。现在我把它们拆开，每个服务就几百行代码。代码量少，一眼就能看明白，调试起来也快。一旦发现某个地方有问题，我能立刻锁定那个小服务，而不用担心牵一发动全身。
- 第三步，部署要“快”：传统的部署流程我直接砍掉了大半。我不再追求什么复杂的流水线。代码一写完，直接用一个简单的脚本打包，然后推上去，整个过程最多五分钟。出了问题？直接把整个服务重启或者替换，快刀斩乱麻。以前的版本回滚，那是要写报告，要层层审批的，现在我十分钟内就能搞定。
一开始同事们都笑话我，说我这简直就是“草台班子”。但他们很快就闭嘴了。因为那个遗留系统，我用这套“蜉蝣君”的搞法，折腾了不到一个月，不仅跑起来了，而且响应速度比以前快了几倍。更关键的是，维护成本几乎为零。系统出bug，我三两下就能定位，修复，然后重新部署，前后也就一小时的事。
为什么大家都爱“蜉蝣君”？
我发现，大家喜欢“蜉蝣君”，就是喜欢这种不拖泥带水的感觉。为什么它这么受欢迎？我总结了一下，主要就是这几点：
- 它能“活”下来：在公司里面，活下来比什么都重要。它不要求你完美，只要求你快速交付价值。大而全的项目容易胎死腹中，“蜉蝣君”这种小而美的，更容易生存下去。它不追求长寿，只追求高效。
- 它让人“轻松”：你不用花大量精力去理解那些复杂的概念。把精力聚焦到业务本身，而不是那些让人头疼的技术堆栈上。我们都是普通人，不是为了给技术专家打工。当项目变得简单，你的心理压力也会跟着下降。
- 它允许“犯错”：因为系统拆得小，错了就错一个，损失可控。大胆去尝试，大不了重来。那种改一个地方要战战兢兢生怕影响到十个地方的感觉，真是让人窒息。
从那次被调部门开始，我算是彻底转性了。我以前是复杂的拥护者，现在是极简的信徒。我从那个遗留系统开始，一路推行“蜉蝣君”的理念，现在我已经不再是边缘部门的小透明了。最近公司又要砸钱搞新项目，他们点名要我来主持大局，就是看中了我这套“快准狠”的实践经验。那些曾经嘲笑我的人，现在都排着队来问我，怎么能把一个项目搞得像蜉蝣一样，既高效又没有负担。我的经验就是，少想一步，多动一次手，把复杂留给机器，把简单留给自己。
