微信扫一扫
分享到朋友圈

我作为开发者犯过的 2 次愚蠢的错误

作者:程序员的那些事 来源:程序员的那些事 公众号
分享到:

07-03

(点击上方蓝字,快速关注我们)


编译:伯乐在线/dimple11


上周我和同事们简单地聊了聊我们工作中搞砸的那些事。如今早已不再犯那些错了,所以想起过去就觉得很好笑。但是笑归笑,其实当时犯的这些错让我们受益颇深。


(credit:Snecx)


分享自己犯错的经历至关重要,能让别人从中吸取经验教训,而且可能让他们工作起来更上手。我在这儿记录了几条自己最近犯的错。


为什么有那么多生产数据库被误删?


几个月之前,Reddit 上发了一篇文章,写的是一个入门级开发人员在上班第一天就误删了生产数据库。我们看到类似这种有人犯了特大的、不可磨灭的错误的文章,都不免心生畏惧。我们意识到自己并不是没可能犯那种错——大多数时候都是悬崖勒马。


我在干第一份工作的时候,有一个高级数据库管理员在上班第一天就误删了生产数据库,这种例子简直比比皆是。工作团队用一周前旧的数据库备份帮他弥补了过失,让他保住了工作。如今十年过去了,都仍用这件事拿他开涮。


今年年初有天早上,我被叫去调查一个客户生产中出现的问题。他们本来要针对一小部分用户进行产品的 β 测试,但是他们的网站首页突然什么都显示不出来了。我猜想可能是系统有 bug 或者有漏洞所致。


我登录进生产机器,调出数据库,发现 articles 表是空的。OK,这证实了网页显示空白的情况。


用户表里面还是有用户的,这就奇怪了,所以我们丢了所有的 articles,但起码他们的测试用户仍有他们的账号,我们可以解释说是这是个测试版,而且这种事情时有发生。


接下来一会儿我就犯迷糊了。我记不清楚自己干了什么,我认为自己不会蠢到在控制台窗口输入了删除表中用户的指令,可情况就是这样——现在既没有 articles 表,也没有用户表。我呆坐着,感觉有点震惊。


然后我的大脑高速运转,开始想办法修复问题。我真的删掉用户表了吗?是的。我们运行备份数据库了吗?没有。该怎么向客户解释呢?我不知道。


我记得自己去找了项目经理,坐在她旁边解释事情发生的经过,articles 表中没有数据了,所以网站看上去是空的。哦对了,我还误删了用户表。现在他们需要重新邀请所有的用户——如果他们还能想清楚用户都有谁的话。哎呀。


我回到自己的座位上,感觉深受挫败。


但是我觉得事情有些蹊跷,我们怎么可能一开始就丢了所有的 articles 表呢?于是我继续深究下去,一方面是因为难以接受这个结果,一方面是想挽回颜面。之后过了一小会儿,我注意到了关键问题。


服务器上还有另外 5 个数据库,其中一个的名字和我正在看的那个数据库的名字非常相似。


我一检查,发现 articles 都在里面,用户表也完好无损。事实证明是因为配置发生变化,无意间让它变成了生产数据库,导致网站指向了全新的数据库。我在里面看到的那些用户呢?种子数据罢了。


真是如释重负!一早上神经紧绷、胃酸翻涌,搞得我浑身不适,但好在我们“修复”了所有的数据,并且找到了问题真正的症结所在,没有提前宣布误删数据库的坏消息。


这个小插曲让我们受益良多,最简单的一个就是:现在我们总是在给数据库做备份……这可能是我们开发人员最有效的胃药。


总赶进度,却从来赶不上进度


我最近所犯的另一个突出 错误没那么戏剧化,实际上是由一个个小错误最终累积造成了大麻烦。


我们项目开发的一大挑战就是时间紧张(但也不全是?)


第一次开会时,我们一致觉得项目需要的时间比我们能够拿出来的时间多了一倍。从项目一开始,截止日期就步步紧逼,所以我们三下五除二就通过了认证环节,以便进入客户真正关心的功能环节。


我只是之前在一个单页 app 中落实了一次认证,但仍然没有彻底理解 app 各部分是如何协调的。


尽己所能用最快的速度把 app 赶出来,就是大错特错,我漏掉了一些非常重要的东西:


  1. 用户在登陆后,是通过 cookie 来加载的,但是我的 app 页面没有给加载提供等待时间,而是根据事件顺序来决定先后的,所以服务器会回复说你没有权限。这种错误很少见,而且很难再出现,因为大多数情况下事件都是按照正确的顺序来完成的。

  2. 而且认证环节也从不检查用户令牌是否失效,如果你不经常访问网站,当发现了没法登上网站后,就需要注销登录再重新登进去。

  3. 令牌应该在每次发起请求时都进行更新,但我从来都没有时间去理解这些规则。所以这里又产生了时间问题。如果我们一次同时发出几种请求,收到的回复取决于他们到来的顺序,那将来发送请求用到的令牌就是错的。


我们卯足劲赶进度,但最终所用的时间还是要比给定的时间多一倍。区别就是我们开发出的 app 里面漏洞更多了,然后甚而要花更多的时间对漏洞进行追踪和修复。


工作中的失误让我尴尬不已,在大家面前感到十分羞愧,因为我把一切都搞砸了。


我要说一点:从那之后,我开始花时间学习认证机制,现在已经理解了 OAuth,、JWT、刷新令牌和失效。我仔细阅读了许多库里别人写的认证代码,而且建立了基于几种不同语言版本和框架的认证流程。


失败是成功之母


这是每次失败的经历给予我的启发。只要你愿意学习,几乎每次这样的经历都会让你从中受益。


如果人能够从错误中吸取教训,那么就会有所进步。如果一个队员是第一次犯错,我尽量不会对他表现出不满态度,他们往往已经知道自己把事情搞糟了。


但我也努力不去苛责那些总是犯错、屡教不改的人,他们也需要被同情。


对待犯错,如果你能够做到这四点,那么就会不断进步:


  • 对曾经犯过的错误可以自嘲一番

  • 从中吸取经验教训

  • 在之后努力为自己正名

  • 和他人分享,让他人也能从中获益。


关于犯错的宝贵价值,我留给你们一则名人轶事:20 世纪初期,IBM 的总裁托马斯·J·沃森遇到了一位因为多次决策错误让公司损失惨重的员工,当问及是否要开除这个员工时,沃森答道:


“不,我刚刚花了 60 万美元培训了他,我怎么会让其他人雇佣他来获得他的经历呢?”


你过去犯过哪些有意思的错?来一起分享吧!



【关于投稿】


如果大家有原创好文投稿,请直接给公号发送留言。


① 留言格式:
【投稿】+《 文章标题》+ 文章链接

② 示例:
【投稿】《不要自称是程序员,我十多年的 IT 职场总结》:http://blog.jobbole.com/94148/

③ 最后请附上您的个人简介哈~




关注「程序员的那些事」,不错过圈内事

阅读8420
开发者 
举报0
关注程序员的那些事微信号:iProgrammer

用微信扫描二维码即可关注
声明

1、头条易读遵循行业规范,任何转载的稿件都会明确标注作者和来源;
2、本文内容来自“程序员的那些事”微信公众号,文章版权归程序员的那些事公众号所有。

评论
更多

文章来自于公众号:

程序员的那些事

微信号:iProgrammer

邮箱qunxueyuan#163.com(将#换成@)
微信编辑器
免责声明
www.weixinyidu.com   免责声明
版权声明:本站收录微信公众号和微信文章内容全部来自于网络,仅供个人学习、研究或者欣赏使用。版权归原作者所有。禁止一切商业用途。其中内容并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。如果您发现头条易读网站上有侵犯您的知识产权的内容,请与我们联系,我们会及时修改或删除。
本站声明:本站与腾讯微信、微信公众平台无任何关联,非腾讯微信官方网站。