注：答应讲的发生在Google的事故的故事，请等下一篇。
阿里月饼事件，给了码农一个警示，一个教训，不好好写代码，后果很严重，最严厉的到开除（虽然我觉得在月饼这个事情上处理有些太重了，也根本不是利用什么安全漏洞）。
一个作为事件的当事人的码农在知乎上描述了事情的经过。
9.12 14:00 听说开始秒杀月饼了，中秋想去一个亲戚家，公司发的月饼送人了，于是想秒一个。
刚开始用手点发现打开就没了。看了下有人用程序刷，于是我和旁边同事说，我也得写个脚本了，要不然抢不到了，于是写了一段js，大概就是如果按钮变成了秒杀就狂点（和12306抢票插件类似），然后处理下验证码。写了个定时器抢16:00的那一批。
由于之前没进入过付款页面，以为和正常的秒杀页面一样，抢到了就会跳转到支付，所以完全没放在心上就去工作了。结果到16:00一看傻眼了，那个页面秒杀可以一直点然后不跳转！我看了下一公是抢了16个（都没付款），然后赶紧给行政打电话说要退，这个我周围的同事都可以作证。
后来的事情我也是猝不及防，16:30 约谈，17:30 解约合同就备好了，18:00走人，走之前还特意问了下需不需要交接工作，大家都不care，走的事情比较重要。
从公司文件和媒体报道来看，把开除的原因归咎于没有遵守企业的文化，归咎于阿里的HR问题，等等。这些，我们无心评论，但是从码农看码农的角度来说，更倾向于从自身和技术找原因。实际上从描述本身就暴露了这位码农写代码的弱点：对待代码这个事情，不管是写个玩具程序，还是实用程序，还是线上产品，都必须严肃，认真，细心，负责。这是一种基本素质的要求，训练有素的体现，良好习惯的保证。
没有好好写的代码，很容易酿成事故。设想这位码农的带有无穷循环的脚本（计数器），如果被很多用户使用的话，很可能造成DDOS攻击。平时也听闻，一个不经意的delete命令，就可能把磁盘上的所有目录和文件都删了。数据库上的一个delete命令，也可以把整个数据库都清空了。我们公司就发生过这种情况，一个工程师的一条数据库维护命令，清空了生产线上数据库的所有内容，最后只能启用备份的数据，费时费力，还影响了客户的工作，怨声载道。
这位码农没有养成良好的代码开发习惯，很显然代码没有经过测试就使用了。否则的话，他说道的之前没进入过付款页面，抢到了没有跳转这个问题，如果他写完代码，就在他的机器上简单测试一下就应该能够发现了，因为他的部署环境和测试环境是一个环境。按键变成秒杀就狂点，还要处理验证码，还有定时器，这位码农居然没有任何测试就能认为脚本能够成功执行，信心可真高。
再看js脚本的计数器，一般是类似如下无穷循环的代码来实现：
function timedCount() {
setTimeout("timedCount()",1000)
}
如果这位码农好好写代码的话，那么在秒杀成功的时候，他应该调用 clearTimeout()来及时退出上面无穷循环的计数器。在任何有无穷循环的地方，都应该警惕，如果脚本被很多人运行的话，弄不好就可能造成DDOS，造成整个服务瘫痪。
这位倒霉的码农，正好赶上了没有好好写秒杀代码的码农，相信这个秒杀应用不是为了这次月饼而临时写的。像秒杀这种应用，好好写代码的码农一定会考虑刷单的问题，可是看上去他们没有。若有，至少，他们应该设一个cookie，如果发现某个用户已经抢到了，就应该在一段时间内不能再抢，防止一个用户持续刷单。要是这样设计和实现，这位码农就不会抢到16个，也不会被行政发现是程序抢单，也不会被HR以维护企业文化而悲剧了。
总之，通过这个事情可以看出，码农无论写什么代码，玩的，实验的，还是产品的，如果没有养成良好的写代码习惯，忽略代码测试，不好好写代码的，一旦出事，代价难以估计，后果将会很严重，开除也不是不可能的。
切记切记，写代码，任何代码，要写，就好好的认认真真的写。否则，宁愿不写！
－－－－－ The End －－－－－
大家可能还感兴趣：
谢谢。
