离谱！17年老程序员惨遭开除，仅因发现一个严重Bug？CTO直言：你说的全对，但“给团队压力太大”

整理 | 郑丽媛

出品 | CSDN（ID：CSDNnews）

如果你是一名程序员，某天在新公司里做出了一个上线即赚钱的产品，还被 CTO 公开称赞，接下来会发生什么？升职加薪？更多项目？

对一位网名为 WorstDeveloperEver（下面简称 WDE） 的程序员来说，故事却急转直下：在短短两天之内，他就从公司的“明星开发者”变成了“被开除的人”——而原因，仅仅是因为他发现了一个后端安全 Bug，并试图帮忙修复。

更荒唐的是，CTO 在通知 WDE 被开除的时候，还亲口对他说：“你说的全对，但我们不能留你。”

这场离奇的遭遇在开发者社区引发了大量讨论。有人说他“躲过了一颗大雷”，有人提醒他千万别心血来潮搞破坏，还有人建议他干脆自己把产品独立重新做一遍。那究竟发生了什么？下面我们来还原一下这段“魔幻职场故事”。

两个多月独立交付SaaS 产品，变身“明星开发者”

WDE 是一名有 17 年开发经验的资深全栈工程师。两个月多前，他加入了一家小型创业公司，当时被安排的任务是从零开始开发一款全新的 SaaS 产品，并且要求尽量减少依赖、保证极致的轻量化。

对资深开发者而言，这既是挑战也是证明实力的机会。最终 WDE 交出的成果堪称 “教科书级别”：整个项目体积控制在 300KB 以内（ 200KB 是优化过的 WebP 图片，100KB 是打包后的核心代码），他还做了全面优化，指标全部拉到 100/100。

该产品一经上线，便开始为公司带来实际收入。CTO 对成果非常满意，当场决定让他再接一个新项目——此时的 WDE 无疑是公司眼里的“明星开发者”，看起来，一切都顺风顺水。

意外转折：被派去“帮忙”的那支奇葩团队

在新项目的设计和规格尚未准备好之前，CTO 把 WDE 派去支援另一支团队，让他给团队负责人（Team Lead）搭把手，并跟他私下透露，说这个团队的代码写得一塌糊涂，开发人员之间也总闹矛盾，所以希望 WDE 能去帮忙排查下问题。

虽然经 CTO 提醒已经有了一定的心理准备，但亲自接触下来，这支团队还是让 WDE 大开眼界——他长达十七年的职业生涯中，从未见过如此混乱的开发方式：

● Git 操作离谱：他们虽然用 Git，但几乎无时无刻不在 force push（强推）。当 WDE 质疑时，Team Lead 只是让他“别管闲事，专心干你的活”；

● 覆盖提交：WDE 把修复代码部署到 QA（测试环境）后，Team Lead 直接用自己的任务强制覆盖，让他的工作成果付诸东流；

● 篡改分支：Team Lead 还擅自切换到 WDE 的开发分支，删掉他的代码，再强推回去伪装成自己的成果，甚至把他在 Jira 上的任务转到自己名下，只留一句 “他的修复没生效”，却不说明任何问题细节。

● QA 混乱：整个团队的测试人员只有一个 Jira 任务，里面列了成千上万项 issue，就用复选框追踪。当 WDE 问“如何确认问题已修复”时，对方回答“每天手动核对”；再问 “是否符合敏捷开发原则”，得到的答案更离谱 ——“这个任务已经在不同 sprint 里持续了 6 个月”。

总结来说，这简直就是一场软件工程灾难。

指出安全 Bug 反遭指责：“你在挑事，不是解决问题”

如果说混乱的开发流程只是让 WDE “糟心”，那么后续的 “安全 Bug 事件”，则直接成了他被开除的导火索。

在熟悉这个“奇葩团队”的业务时，WDE 发现了一个致命 Bug：后端在返回错误信息时，会泄露大量敏感数据，其中还包括 .env 文件里的私有 API 密钥——这意味着一旦被恶意利用，公司和用户的数据安全都将面临巨大风险。

WDE 第一时间就把这个 Bug 反馈给了 CTO，CTO 也很快安排后端开发去进行修复。

可当 WDE 看到“修复成果”时，却彻底傻了眼：这位后端开发只在单一路由的一个响应里做了处理，甚至还是用最敷衍的“黑名单过滤”逻辑——仅判断 response.url 是否包含“apiKey”字符串，如果包含就把等号右边替换掉。

“这根本没用。”WDE 当场指出这种修复方式的问题：只要用全小写的“apikey”发起请求，或者构造“&apiKey&apiKey”这样的参数格式，敏感信息依然会泄露。出于专业责任，WDE 不仅举了两个测试案例，还写好了正确的修复代码作为参考。

没成想，这番“好心帮忙”却捅了马蜂窝。这位后端开发瞬间炸毛，反过来指责 WDE “不懂装懂”、“总盯着别人的问题挑刺，不专心做自己的事”，还抱怨 “我花了一整天修复，你一句话就否定，纯属没事找事”。

当天WDE 的权限被移除，CTO 决定解雇他

更让 WDE 没想到的是，当天晚上他的 GitHub 权限就被突然撤销。

随后 CTO 找他谈话，给出的解雇理由堪称荒唐：“你给其他开发人员造成了太大压力，公司决定解除与你的劳动合同。”甚至，CTO 还补了一句更矛盾的话：“你说的所有问题其实都是对的，但我们不能留你在公司。”

换句话说，公司明知道问题存在，却选择把提出问题的人扫地出门。

“那几天他们都骂我‘没礼貌’、‘无知’、‘爱耍小聪明’，我昨晚都没睡着。明明我只是说了实话，最后却好像我成了问题员工？”WDE 在帖子中坦言，自己气愤到失眠，甚至一度想利用 API 的自我 DDOS 缺陷，制造日志系统瘫痪来“给他们点颜色看看”。

不过冷静下来后，WDE 还是决定不做违法之事：“总有一天他们会在安全问题上遭殃，但我不想让他们怀疑是我。”

社区热议：问题不在技术，而在文化

WDE 将这件事分享在开发者社区后，引发了许多关注与讨论。

很多程序员指出，其实现实中类似的情况并不少见：

● 一些初创团队缺乏工程文化，依靠“能跑就行”的心态快速上线，经常忽视安全与规范；

● CTO 或管理层更重结果而轻过程，因此当有人触及团队短板时，就被视为“麻烦制造者”；

也有人认为，WDE 其实算是躲过了“一颗大雷”：“读到一半我就觉得，你躲过了一颗大雷。这个团队文化太有毒了，最好别惹他们。想想以后，如果你真的报复而故意破坏系统，会影响你未来职业声誉。”

还有人建议，如果 WDE 有能力可以做出更好的产品，然后“把他们客户挖过来，同时告知漏洞和风险，提供折扣”——这才是真正的商业复仇。

那么，你对于这件事看法如何？如果代入 WDE 的遭遇，你又会作何感想呢？

https://www.reddit.com/r/webdev/comments/1nolmnc/got_fired_from_a_company_for_finding_a_security/

https://www.reddit.com/user/WorstDeveloperEver/