这帖子让我看了直接笑了，“被卸磨杀驴”还真是一针见血。看到这位被“卸磨杀驴”的同学，真替他心酸。这年头，加班没你，走了更没你，还真是随时找驴顶上。至于他问“能不能把代码删除”来报复公司？别急，咱们看看各路网友是怎么说的。
有人说：“要报复，直接在代码里加点小问题，让老板发现不出，却又隐隐觉得不对劲儿，那才是高招。”这位网友脑洞一开，就是加“脚皮屑”的套路，别说，还挺形象。不过咱们程序员操作起来估计得稍微细致点儿，毕竟一不小心就要留下蛛丝马迹了。
想让老板“吃着不对劲又找不出问题”，只能从一些“不易察觉的小细节”入手，比如一些写得略显“模棱两可”的注释，或者给某些变量名字加上点“难以理解”的幽默。看着没啥问题，却能让接手的同事直挠头。
然后，有网友表示：“提交记录发现不了？离职前提交一堆代码，也不让你merge。”这招其实有点意思。临走前猛地提交一大堆东西，让后续维护的同事慢慢消化吧。
不过问题是，这样的代码基本上还是得老板签字才能合并，甚至公司还可能因为没完全理解代码而直接pass掉。总之，这种“批量提交”的方式想要达到效果，还得看公司的管理流程。
接着，还有人泼了一盆冷水：“小伙子，小心点，这样做违法吧？故意破坏公司资产。”法律上的确有说法——破坏公司代码、数据等重要资产，确实能算违法行为。
虽然很多人吐槽“老板不讲武德”，但咱们要是不讲“职业道德”，损坏公司的东西，还真可能被追责。特别是一些大公司，安全措施都很严格，出了问题随时查版本回溯，追溯到你这位“离职小伙伴”可不是什么难事。所以说啊，别轻举妄动。
再来看看一位网友的机智操作：“多写一点错误的注释不就好了？干嘛要去搞破坏呢？”这招不得不说是绝了。看似无伤大雅的注释，实则能给后续维护带来不少“小麻烦”。
当然，前提是注释写得足够“机智”。但写多了“误导性”内容，又容易引来疑心，也算是一种高风险操作。要不，把代码写得像“一看就很正常，但细看又有点怪异”？这么一来，接手的人也得多花点时间，算是悄悄地“留个小心眼”。
最让我觉得有趣的，是有人说：“驴何苦为难驴。”程序员互相为难的事确实多见，谁没接手过一两堆“黑历史代码”呢？最搞笑的是，这段话虽然带着点儿调侃意味，但在现实中确实成立。
老板换驴，程序员一走了之，可后续来接手的程序员十有八九也是被坑得不轻。毕竟，卸磨杀驴不是第一次，也绝不是最后一次。程序员们何必自己坑自己？
最后我觉得，遇到这种情况，倒不如换个角度，聪明一点。不要想着在代码上“动手脚”报复公司，毕竟人走茶凉，留下一堆锅等着后人去背，其实并不划算。
走之前可以适当留下点“个人印记”，比如写一段简洁又绕口的逻辑，给代码多增加点注释说明，哪怕有时这注释是给自己发牢骚呢。等到后来有人看代码时，还真能看出一丝“人在江湖，身不由己”的感觉。
那么大家怎么看呢？你们会不会在这种时候给自己“留个小心眼”？欢迎在评论区留言，说不定还能看到更奇葩的“反击”招数。
那么大家怎么看呢？欢迎大家评论区留言分享！
目前，对编程、职场感兴趣的同学，大家可以联系我微信：golang404，拉你进入“程序员交流群”。
虎哥私藏精品 热门推荐 虎哥作为一名老码农，整理了全网最全《前端资料合集》。
