组里有个P7，为了防止被裁，把核心计费模块的代码写得晦涩难懂，还加了自定义的混淆逻辑，甚至不提交Git， 结果CTO直接招了个外包团队

组里有个P7，为了防止被裁，把核心计费模块的代码写得晦涩难懂，还加了自定义的混淆逻辑，甚至不提交Git， 结果CTO直接招了个外包团队

原创 我是帅sir 我是帅sir Sir求职2026年2月25日 20:02

在小说阅读器中沉浸阅读

前端开发社区刷到一个帖子，组里有个P7，为了防止被裁员，把核心计费模块的代码写得晦涩难懂，还在里面加了自定义的混乱逻辑，甚至不提交Git，只在服务器上保留一份。他的逻辑是：只要公司看不懂这段代码，就不敢动他。

结果CTO直接招了一个外包团队，花了两个月把他的模块从头到尾重新开发了一遍。并行运行验证没有问题后，当天就让他走人了。

赔偿金是按最低标准给的，因为公司抓住了他"违规操作生产环境"的把柄。

其实他的出发点是可以理解的。互联网行业这几年裁员不断，P7这个级别，薪资高、人力成本大，是公司裁员时候重点考虑的对象。他看到了这个风险，想给自己建一道护城河。

把代码写复杂，让别人看不懂，是一种技术上的不可替代性。表面上的逻辑是：你看不懂这段代码，出了问题只有我能修，所以你不能裁我。

这个逻辑，在很多年前可能是有效的。那时候公司规模小、技术管理不成熟，确实有人靠这种方式苟了很多年。但在现在，这条路已经基本堵死了。

现在的公司，尤其是有一定规模的互联网公司，技术管理越来越成熟，外包资源越来越成熟，一个模块如果原有开发者离开，重新找人开发的成本已经大幅下降。两个月，外包团队，这不是什么超级复杂的操作，是正常的技术管理动作。

更关键的是，这个P7犯了一个致命错误：不提交Git。

Git是代码版本管理的基础，不提交意味着公司对这段代码完全没有控制权，一旦这个人走了，代码可能就没了。在技术管理角度，这已经是严重的违规操作，而且这种操作留下的痕迹，对CTO来说是一目了然的。

说白了，他以为自己在布局，其实是在把自己架在火上烤。

我认识一个在大厂做技术管理的朋友，他跟我说，他在职业生涯里遇到过不止一个这样的人，喜欢把代码写得没人能看懂，然后觉得自己是不可替代的。

他说，每次遇到这种人，他的第一反应不是担心动不了他，而是立刻开始评估重写的成本。因为一个写代码不注重可读性、不遵守规范、甚至故意制造混乱的人，他留在团队里的危害比他走掉更大。

他主动清退过两个这样的人，都是外包重写解决，时间比想象中短。他说，技术债务是最终会还的，区别只在于谁来还，什么时候还。

还有一个，就是"违规操作生产环境"这个把柄。

这位P7在服务器上保留代码但不提交Git，而且加了混乱逻辑，这在技术上是可以被认定为违规操作的，因为他绕过了公司的技术规范和代码管理流程。正是这个把柄，让公司可以按最低赔偿标准走人，而不是给他按N+1的补偿。

这才是整件事里他最亏的地方，不仅走得难看，连应得的赔偿都被卡了。

一个技术人员真正的壁垒，应该是：你写的代码清晰、规范、好维护，同时你对业务逻辑的理解深度是别人几年都追不上的；你解决过的那些复杂问题，留下了完整的记录和经验，让团队离不开你的判断，而不是你的代码。

这才是长期有效的护城河。这个P7用错了力气，方向反了，结果不仅没保住饭碗，还把能拿到手的赔偿都搭进去了。

职场里有很多歪门邪道，看起来聪明，实际上都是在搬起石头砸自己的脚。

——————热文推荐阅读——————