55

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

 5 years ago
source link: http://www.10tiao.com/html/200/201807/2655442147/1.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

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


编译:伯乐在线/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/

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




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


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK