我在大厂做开发的5年：那些996的日子

作为一名在互联网大厂摸爬滚打五年的开发工程师如今转型成为软件测试团队的负责人回望过去那些被996填满的日子我有太多话想对同为技术从业者的测试同仁们说。这些经历不仅是我个人的成长印记更藏着开发与测试岗位在高压环境下的共生与博弈或许能为你们理解开发侧的逻辑、优化跨岗协作提供一些不一样的视角。2019年盛夏我怀揣着“技术改变世界”的梦想踏入大厂迎接我的却是比盛夏更灼人的996工作制。每天早上9点到岗晚上9点下班每周六雷打不动加班成了生活的主旋律。最初的我和很多年轻开发者一样将996视为快速成长的阶梯——毕竟能接触到行业最前沿的技术栈参与亿级用户体量的项目每一次加班都像是在为自己的技术护城河添砖加瓦。但没过多久这份热情就被无休止的加班消磨得所剩无几。现在想来996对开发工作的侵蚀从一开始就埋下了测试岗位的隐患。记得有一次我们团队负责一个核心电商模块的迭代项目排期被压缩到极致开发周期从常规的4周硬生生砍到2周。为了赶进度我们开启了“996”模式每天加班到深夜11点是常态。那段时间我的工位旁永远放着折叠床凌晨两点的公司茶水间总能看到同样眼神疲惫的开发同事。在这种高压下代码质量成了牺牲品。为了快速实现功能我们不得不跳过一些非核心的单元测试甚至在代码注释上都草草了事。现在我才明白当时我们省下的每一分钟测试时间后来都变成了测试团队的噩梦。当我们把满是“技术债”的代码提交给测试团队时测试工程师们面临的是一座难以翻越的大山。他们不仅要验证功能的正确性还要为我们的“仓促”买单——排查那些因为代码逻辑不严谨而产生的偶现bug梳理我们没来得及完善的业务流程。有一次一个因为并发处理不当导致的订单重复提交bug测试团队整整排查了三天三夜。后来我和当时负责这个bug的测试工程师聊天他苦笑着说“你们开发写代码的时候快如闪电我们测试找bug的时候却像是在海底捞针。”这句话像一根刺扎在我心里很久。从那以后我开始反思996模式下开发与测试岗位的失衡。996带来的不仅是代码质量的滑坡更是团队协作效率的降低。在长期加班的状态下人的专注力和判断力会急剧下降。我记得有一次我在写一个支付接口的时候因为过度疲劳把金额的单位从“分”写成了“元”。这个低级错误在开发自测阶段没有被发现提交到测试后被测试工程师一眼揪了出来。当时的我羞愧难当不仅因为自己的失误更因为我知道这个错误浪费了测试团队的时间和精力。后来我才发现这种因为疲劳导致的低级错误在996的环境下屡见不鲜。开发工程师们像被上了发条的机器不停地写代码、提交代码却没有时间停下来审视自己的工作。而测试团队则成了最后一道防线承受着来自开发和项目进度的双重压力。随着工作年限的增长我逐渐意识到996对技术人员职业发展的隐性伤害。在大厂的前三年我几乎把所有的时间都花在了项目交付上没有时间学习新的技术也没有时间沉淀自己的知识体系。当行业开始流行微服务架构、容器化技术时我才发现自己已经落后了一大截。而这种技术上的滞后又会反过来影响开发效率和代码质量形成恶性循环。现在我转型做测试管理更加明白持续学习对技术人员的重要性。测试技术也在不断迭代从传统的功能测试到自动化测试、性能测试、安全测试每一个领域都需要持续投入时间和精力去钻研。如果被996束缚了手脚就只能在原地踏步最终被行业淘汰。在大厂的第五年我因为身体原因和对职业发展的思考选择了转型。当我以测试管理者的身份重新审视996时有了更深刻的理解。996本质上是企业为了追求短期利益而采取的极端手段它牺牲了员工的健康和长期发展也损害了产品的质量和用户体验。对于测试岗位来说996更是一种“慢性毒药”。测试工作需要严谨的逻辑和敏锐的洞察力而长期加班会让测试工程师们身心俱疲无法保持最佳的工作状态。很多测试工程师在996的压力下不得不降低测试标准放过一些潜在的bug这对产品质量来说是巨大的隐患。现在的我在管理测试团队时始终坚持“拒绝无效加班追求高效协作”的原则。我会和开发团队一起制定合理的项目排期为测试工作预留足够的时间我会鼓励测试工程师们主动和开发工程师沟通在需求阶段就参与进来提前发现潜在的风险我也会为团队争取更多的学习和成长机会让大家在工作之余能提升自己的技术能力。我深知只有开发和测试团队紧密协作才能打造出高质量的产品而这一切的前提是让每一位技术人员都能在合理的工作时间内发挥出最大的价值。回望这五年的996岁月有汗水有遗憾也有成长。它让我明白技术的价值不在于加班的时长而在于代码的质量和对用户的责任它也让我懂得开发与测试不是对立的两端而是相辅相成的伙伴。希望我的经历能给各位测试同仁们一些启发在未来的工作中能更好地理解开发侧的困境也能更坚定地守住质量的防线。毕竟我们都在为同一个目标而努力——打造出让用户信赖的好产品。