因试用期遭劝退，一男子为发泄情绪删光自己在职期间所写系统代码被判刑十个月，如何看待这一审判结果?
通过删库来发泄情绪的程序员是最蠢的。
聪明的程序员会写一堆只有自己看得懂的屎山，并且伴随着偶发且不可复现的重大bug。
一旦离职，屎山将变得不可维护。
然后你不但不需要自己删库，老板还需要花额外的钱请其他程序员来删掉你的代码。
屎山包括但不限于以下行为：
使用大量while语句和条件判断，并在之间加塞大量自定义函数和实例化以及递归结构。并把函数暴露在其他人可以灵活修改的位置，只要一个参数变化就会导致函数返回出错，卡死在while循环。而debug通常需要几千个循环之后才能发现，极大的延缓了bug被修复的时间。
函数套函数形成千层夹心，让思路乱做一团，很难理顺思考。
继承套继承，乱用面相对象，当接盘侠看懂了这个类，却发现这个子类继承了多个父类，还有接口冲突。而当他们想看看父类的时候，却看到这几个父类又继承了几个父类。
DFS搜索了一遍父类，想找到某个方法和属性。方法父类和祖父类都被架空了，于是找到了曾祖父类，结果发现这个方法包了一个buildin type的buildin 方法，且只有一行return。属性父类和祖父类都没有定义，结果找到了曾曾曾祖父类，终于发现了，这个属性的值是null。
灵活修改内置函数，类，属性，原本想用内置功能，却发现要用了一个带bug的自定义内容，后续的代码还有大量功能是基于这个披着内置函数的名字的自定义bug运行的。
随意起名，并和全局变量保持一致，不经意间就修改了全局变量。
catch所有的exception，让bug被巧妙隐藏。
使用复杂多线程多进程服务，并伴随着随机函数和等待时间，让bug很难出现。
大量使用外部api请求，并写死提取方法，一旦对方api修改，立刻出bug。
在数据库交互函数上灵活实现，让使用者可以传入任何值，修改数据库的任何内容，甚至只要传错一个参数就可以删掉数据。
一定不要写，单元测试，也不要写document，把你的所有的时间用在老板能看得到的功能实现上，而且一定要用最复杂，最fancy的实现方式。面对老板不切实际的需求来者不拒，只要让老板在看到功能时候保持运行状态即可。
实现的论文一定要用最冷门的巨巨技术，冷门意味着没几个人会甚至连业内人员都没学过，巨巨意味着难难到只有苦心钻研黑科技的你才能把抄来的代码勉强跑起来。
一定要拉上业界最顶级的框架，绝不按照项目自定义内容，如果一个顶级框架不能完成就再加塞一个顶级框架，每个框架只用一点点内容，以此来显示你超强的学习能力和业务素质。这样如果有人要接手，他们需要把这些框架全部学一遍。
并且经常使用那些不稳定但勉强能用的新版功能，无视大量warning，如果有就隐藏掉。旧版功能通常难以被新版支持，所以这些框架的版本在你引入项目的瞬间就被定死了。
然后为了保险起见你不要升级框架，一定要用最老的框架，这样一个毕业生误以为学会了框架内容结果却发现自己学的框架太新了，还得把旧版本的内容学一遍。
经常使用开源bug书写程序，这样一旦开源库修复bug，你的代码就需要重写。
如果写http请求，请一定把最危险的功能设置成get方法，这样只要在聊天时对方点误点了连接，浏览器就会自动把危险的请求传给后端，然后造成大量业务崩溃。但这不是你的错，是他们不应该在聊天和邮件里乱点链接！
一旦你离职，你所写的所有代码和同事的代码都会随着开源版本更新，新功能增加，外部api变化，新同事不小心传错参数，以及点错超链接造成大业务坏死。
让fancy的地方尽可能简陋，让简陋的地方尽可能fancy。就能在满足其要求的情况下，引入大量bug和feature的混合物，让改动变得左右为难。
这就让接手的程序员陷入如下困境：
删除代码重构，工作量太大
不删代码，看不懂源码
清理bug，功能变得不可用
不清bug，之后会引发严重问题
维护代码，只能用新bug掩盖旧bug
不维护代码，随着技术升级，旧代码会一点点变成bug
当你已经掌握这些技巧，并付诸实践，想必公司一定得让你晋升主管。
为了清理这些垃圾需要耗费成倍于你的人月方可完成删除，然后为了实现你的功能他们又需要额外的人月
清理屎山可不止恢复数据那点钱。
