离职两年后,程序员遭前东家索赔:Bug是你写的

VSole2023-03-23 09:56:39

问:身为一名程序员,你能确保至今写的代码中没有一个 Bug 吗?

程序员:当然不能。

问:那你不怕这些 Bug 导致重大损失,然后公司起诉你吗?

程序员:哈,还有这样的事?

嗯,确实有的,甚至还发生在员工离职后——近日,杭州一名程序员在社交平台爆料:“本人程序媛一枚,离职两年被之前公司要求经济赔偿,理由:代码是你写的。

因代码问题,被前东家起诉追责?

根据这位程序员(以下用“小 C”代称)提供的时间线及相关细节,我们先将这件看起来颇为“离谱”的事情捋一捋。

2019 年,初到杭州的小 C 进入了杭州某公司(位于杭州滨江,因事情还没结束,小 C 没有明确说明公司名称)任职。当时拥有一年系统开发经验的她,独自负责了某个功能的开发,且该功能在她 2020 年离职前已顺利上线。

然而今年年初,从这家公司离职已两年多的小 C,突然被前小组领导找上了,说她之前负责的功能代码有问题。考虑到当初在职期间,公司同事和组长们都对她比较关照,所以虽然已经离职,小 C 也多次给予协助,并找出了问题原因

始料未及的是,不久后该公司就开始追究小 C 的责任了,认为是她的代码问题导致公司严重损失——代码存在逻辑问题,违反行业经验及常理。此外,该公司还发了通告函要求小 C 到现场进行说明,但当时小 C 认为问题已做解决,又因异地 + 手头工作繁忙,做完说明便拒绝了这个要求。

结果,小 C 就收到了法院短信——她被该公司起诉了,要求赔偿几十万的损失,被告共两人。其中,该公司起诉小 C 的理由是:

被告作为代码撰写人具有有效期,但在最终的代码处理上未做逻辑处理规避风险。原告认为,根据行业经验及常理,系统运营的期限限制是代码撰写工作最重要且最基础的内容之一,被告放任及不负责的处理方式直接导致了原告的损失,其行为具有明显的主观故意或重大过失。

至此,这件事情就捋明白了:一名程序员已离职两年,但她离职前写的代码有问题,导致现在发生严重损失,于是公司要求追责并赔偿。

写代码是终身责任制吗?

这名程序媛将此事曝光不久,便引来了诸多关注与争论,其中讨论焦点主要在于:“代码撰写人具有有效期?有效期多久?终身责任制吗?

事实上跟小 C 类似,不少程序员也在离职后收到过前东家的“返工”请求,有的要解释代码,有的要修复 Bug,还有的希望能帮助指导下一任负责人交接——颇有些“一次交付,终身维护”的意思。

关于这个话题,前阵子知乎上也发起了类似讨论:“为什么程序员的代码不能终身责任制?”对于广大程序员来说,这个问题的答案很简单:“程序员如果需要为代码终身负责,那你就需要终身给这个程序员开工资。

正如一位网友所说:一旦代码执行责任制,这就说明代码属于程序员,既如此公司也就无权使用离职程序员的代码;可如果说代码属于公司,那离职后代码出问题,又为何与程序员有关?

诸如此类,因而多数网友对小 C 前东家的做法都不予苟同:

  • “笑死我了,那你让他代码产生的收益也给你。”
  • “所以这位程序员离职之后代码运行完好这段时间的收益什么时候结算一下?这时候你不提代码是公司所有了是吧?”
  • “程序员在公司写的代码均为公司所有,没有做好 code review,测试就上线而引发的损失,与程序员本人无关,最多绩效垫底,工资都不得拖欠,更何况已经离职。”

此外,结合该公司对小 C 的起诉理由,许多人认为这只是一种恐吓方式,想把小 C 推出来“背锅”,甚至这场官司就算要打,小 C 也输不了:

  • “不是真想让你赔,只是内部员工想推只羊出来应付查这个事的领导。两年前的事肯定没有人能说清,当事人也说不清,也没人敢说谁对谁错,所以你就被推出来了。”
  • “首先,违反行业经验及常理?这里的行业经验是什么经验,常理又是什么常理,建议公司必须详细说明。其次,代码要经过好多人的手去写,不断经过不同人的迭代,功能上线两年了,最后也无法确定是哪个人的代码有问题吧?”

最后,关于这起事件,CSDN 也咨询了 ChatGPT 的看法:

那么,你对于这件事,又有什么想说的呢?

程序员写代码
本作品采用《CC 协议》,转载必须注明作者和本文链接
之前在打CTF的时候,多次遇到了这个漏洞。 攻防演练期间,研究了一下蜜罐的骚操作,比如获取百度ID、CSDN账号、微信ID等等,对攻击者进行攻击者画像。 学习了一下原理,然后做了一些改进,利用MySQL的漏洞,获取攻击者手机号。 本系统代码非完全原创,部分代码参照 https://github.com/qigpig/MysqlHoneypot。 关于MySQL任意文件读取漏洞,网上很多大
学习了一下原理,然后做了一些改进,利用MySQL的漏洞,获取攻击者手机号。关于MySQL任意文件读取漏洞,网上很多大佬了很详细的分析文章,本文不再复述。
雷布斯强的一批。
8月6日,深信服研发架构师赵振阳受邀出席由中国信息通信研究院等单位联合举办的“边缘原生”技术沙龙,并做《深信服边缘关键技术及落地实践》的主题分享。在分享中,赵振阳介绍了边缘计算面临的主要挑战,深信服在云边协同、边缘计算上做的探索和方案,深信服基于开源社区对于边缘计算、云边协同一些能力建设和考虑,以及如何使用边缘计算帮助用户解决实际问题。
代码存在逻辑问题,违反行业经验及常理。”
斯坦福大学的一项研究发现,使用人工智能助手编写的代码比“手工代码”的安全性差很多,而且人工智能工具还会导致用户对其代码中的安全性过于自信。
每次聊到代码优化,都会有很多人说理论、架构、核心思路,其实我觉得代码优化这事说简单了很简单,说复杂了吧它也有一定的难度,但是我觉得有一个良好的编码习惯很重要,下面分享一下14个springboot项目中优化代码的小技巧,让代码优化跟容易,就像完成一件小事。
说实话,我非常希望自己能早点看到本篇文章,大学那个时候懵懵懂懂,跟着网上的免费教程做了一个购物商城就屁颠屁颠往简历上。至今我仍清晰地记得,那个电商教程是怎么定义接口的:管它是增加、修改、删除、带参查询,全是 POST 请求一把梭,比如下面这样:修改用户的收货地址。现在看来,全部用 POST 请求估计是为了传参方便吧。本文希望通过串讲,梳理一下个人当前了解到的 API 知识体系,整理的同时也希望能对大家有一点点帮助。
Bob大叔在《Clean Code》一书中谆谆教导我们:要对变量、函数、类精心命名,避免耍小聪明,别使用双关语。这个结果让我立刻想到了Linus Torvalds,他经常Fuck 这个,Fuck那个的,Linus在内核源码中对别人代码的评论就足以扭曲统计结果。而 idiot* 则一致是在缓慢上升,现在和damn* 并驾齐驱,不分上下。在Java社区,开源代码中的脏话也不少。3天后,经过 OpenJDK 社区讨论,大家认为:Damn 和 Crap 不算脏话!
代码不意味着低风险。通过让企业中更多的人能够开发应用,低代码开发会产生新的隐患,并且会潜藏安全问题。
VSole
网络安全专家