躲避加班洪流：一个IT人的躺平实践
大家好，我是阿凯，在互联网公司做后端开发已经有八年多了。从一线码农到技术骨干，我经历过初创公司的激情创业，也感受过大厂的规则与节奏。这八年来，我的工龄在变长，项目经验在积累，但最深切的感受却是——这个行业对“加班文化”的推崇，远超了它的创造力和人文关怀。
今天想和大家分享的是我在一次大型重构项目中，如何在高强度工作压力下，选择“躺平”，反而让项目走出了僵局，同时也让我重新思考了工作的意义和价值。
项目背景：一场注定不平凡的重构
去年年底，我们团队接到任务，要对已上线多年的主干系统进行一次架构级重构。这套系统是公司的核心业务支撑平台，涉及用户中心、订单处理、支付结算等多个关键模块，已经持续运行超过六年。
项目初期，管理层给出的目标很明确：
- 三个月内完成初步迁移
- 零故障切换、零数据丢失
- QPS提升至少30%
听起来像是一个技术升级的好机会，但实际上，我们面对的是一场没有退路的硬仗。旧系统采用的是单体架构，所有代码集中在几个核心应用中，数据库表数量超过150张，服务调用错综复杂，文档更新滞后严重，甚至连一些关键接口的作用都需要靠老员工口口相传来确认。
更糟糕的是，项目组成员每天都在讨论“谁去负责哪个模块”、“怎么拆分服务”、“要不要引入Kafka或者消息队列”。所有人都在忙着写方案、画图、开会，却没人真正动起键盘开始编码。
而就在这时，我选择了“躺平”。
那段时间的真实写照：一边焦虑，一边放空
说实话，我并没有一开始就选择躺平，而是被现实“推着躺下”的。
刚开始那两周，我也像其他同事一样拼命梳理需求、画架构草图、设计API。但很快我就发现：每个人都在重复造轮子，没人能确定当前进展是否有效，甚至不知道目标到底是什么样子。
举个例子，有个同事连续三天熬夜写了份微服务拆分方案，结果第三天上午会议上被产品经理一句话否掉了：“这个拆法不符合业务逻辑，换种方式。”那一刻，我看到他眼里的光瞬间熄灭了。
我自己也陷入了这种怪圈：白天开会、晚上写代码、半夜改方案，整个人精神极度疲惫。有几天甚至凌晨两点还在查日志，早上七点就被钉钉吵醒说某个接口出错了。
我开始怀疑这一切的意义：我们是为了交付质量更高的系统，还是只是为了按时交付？如果方向都不一致，努力又有什么用？
于是，我决定暂停一切忙碌，先停下来看看自己。
停一停，看看方向在哪里
我给自己设了一个“观察期”——整整三天，不主动参与任何会议，不提新建议，也不接具体任务。我只是默默看别人怎么做，问自己几个问题：
- 我们现在做的每一件事，真的有必要吗？
- 如果不做这些事，会不会影响最终目标？
- 这些事情，是由谁决定的？
没想到，这三天成了整个项目的转折点。
通过观察，我发现了很多以前没注意到的问题：
- 很多技术方案其实根本无法落地，因为缺乏详细的测试环境配置；
- 团队里有人在重复开发功能相似的服务；
- 有些所谓的“高性能优化”实际上只是增加了架构的复杂度；
- 最要命的是：没有人真正了解用户的实际使用场景。
于是，我整理了一份“项目瓶颈清单”，里面详细列举了当前项目的三大痛点：
- 技术决策脱离业务本质
- 缺乏统一的技术共识
- 持续集成/部署流程混乱
并提出了一个大胆的想法：
“我们能不能换个思路？不要急着开工，先做原型验证。”
技术选型：从Spring Cloud转向轻量级架构
我们的旧系统是基于Spring Boot+MyBatis的老派写法，虽然可维护性差，但也算稳定。而团队很多人在推动向Spring Cloud转型，希望引入服务注册、配置中心、链路追踪等一套完整的微服务生态。
但我心里总觉得不对劲。
微服务不是万能解药，尤其是对我们这种团队来说。
首先，我们需要考虑运维成本。如果我们贸然引入Eureka、Zuul、Config Server等组件，不仅需要搭建整套基础设施，还要培训团队成员熟练掌握。这对一个只有8人且多数为中级工程师的团队来说，无疑是个巨大挑战。
其次，我们并没有足够的测试覆盖率，也没有成熟的发布机制。一旦线上出现服务注册失败或断链，很可能引发雪崩效应。
因此，我提议：
“我们不妨先尝试轻量级拆分，只做服务边界划分 + 接口标准化，先把业务拆通再说。”
技术选型上，我们采用了以下策略：
- 继续使用Spring Boot：作为基础框架，保持稳定性；
- 引入OpenFeign作为通信中间件：代替传统的RestTemplate，更易维护；
- 使用Swagger + SpringDoc组合构建标准化接口文档；
- 前端页面使用Node.js+Webpack构建静态资源包，避免后端混杂渲染；
- DB方面采用Sharding-JDBC做读写分离，逐步过渡到分库分表。
同时，我们在CI/CD环节做了简化：
- 使用Jenkins+Docker构建打包；
- 每个服务独立打镜像；
- 上线前必须跑通单元测试+自动化测试用例；
- 引入Graylog做日志集中管理。
整个过程下来，我们并没有盲目追逐“高大上”的技术，而是围绕着“能不能快速验证”、“有没有足够人力支持”来做权衡。
实践过程：从小步快跑开始验证
第一步，我们选了一个最小可行性模块试点：用户中心的基础信息模块。
原本它和其他模块耦合在一起，依赖项高达十几个，接口数量上百。我们将这个模块单独抽离出来，作为独立微服务运行，并将其接口标准化，提供给其他模块调用。
这一步花了不到三周时间，期间我们反复调试接口兼容性、测试性能瓶颈，甚至模拟了多个并发用户访问场景。结果证明：即使不引入Spring Cloud，也能实现高效的服务拆分和对接。
更重要的是，这个小试点让我们看到了两个关键变化：
- 团队成员开始有了明确的分工，知道各自在做什么；
- 更重要的是：我们不再一味追求“先进”，而是注重“可用”与“可控”。
接着，我们逐步将其他模块按照优先级顺序进行拆分，每个模块都保留了自己的测试用例和部署脚本。到了第二个月底，我们已经完成了70%的核心服务迁移，并且整体QPS提升了42%，比原定目标还高出不少。
最重要的是——大家都轻松了很多。
经验总结：躺平，是一种理性选择
回顾这段经历，我意识到一个道理：
在高压环境下，盲目冲刺不如冷静思考，有时候“慢”才是真正的“快”。
我们总被催着上线、改方案、开会、做PPT，却很少停下来思考：这件事是不是真有价值？我们做的事情，能不能沉淀下来？
躺平并不是消极放弃，而是在复杂的环境中做出的一种自我保护和理性判断。对我来说，躺平是：
- 不再盲从主流技术方案，而是选择适合自己团队的方式；
- 不再死磕性能优化，而是先确保基本功能正常运行；
- 不再参与无效会议，而是把时间留给真正有价值的产出；
- 不再为了“卷”而卷，而是学会平衡工作与生活。
给同行朋友们的一些建议：
技术选型要务实
别被“某某大厂都用了XXX”迷惑，适合自己团队的才是最好的。比如我们当时坚持不用Spring Cloud，就是考虑到学习成本和运维难度。沟通一定要简洁高效
每次会议都要有产出，否则不如不开。我现在的习惯是：会前发一个议题文档，会上只解决重点问题，会后直接输出结论文档。别怕“掉队”，要学会辨别方向
当大家都在忙的时候，也许正是你停下来思考的机会。很多创新和突破，都是在别人“卷不动”的时候发生的。重视工程化和可持续交付能力
再牛的技术方案，如果部署不了、测试不了、维护不了，那也只是空中楼阁。我们后来之所以顺利推进，就是因为提前建立了完整的CI/CD流程和测试体系。
后记：选择躺平，不代表我不热爱技术
很多人问我：“你不卷了吗？”
我会回答：“我还在卷，只是不再为‘卷’而卷。”
我喜欢写代码，喜欢研究新技术，也喜欢解决问题带来的成就感。但我知道，真正的技术进步从来不是靠996堆出来的，而是一个个清晰目标、一次次合理规划、一步步稳妥推进的成果。
在这个处处强调效率、强调投入感的时代，愿每一位开发者都能找到自己的节奏。愿我们都能够在代码的世界里，保有一份理性和清醒，也保有一份内心的温柔和平静。
如果你也曾在深夜加班、心力交瘁的时候想过“算了，躺一会儿吧”，那我想说：没关系，休息一下也没关系。技术这条路很长，慢慢走，才能走得更稳，走得更远。
评论 0