秘密潜入2小辣椒

by Zachary Kuhn

扎卡里·库恩(Zachary Kuhn)

那两次我显然不知道我作为开发人员正在做什么 (Those two times where I clearly had no clue what I was doing as a developer)

Last week I had a short conversation with coworkers about how we had messed up in our careers. Being so far removed from those mistakes, it was easy to laugh. More than laughs, though, these screw-ups served as powerful lessons for us.

上周，我与同事进行了简短的交谈，讨论了我们如何陷入职业生涯。远离这些错误，很容易发笑。但是，这些笑话不仅为我们提供了有力的教训，还为他们带来了很多教训。

It’s important that we share our mistakes so that others can learn from them and maybe feel more comfortable with their own. So here are a couple of my more recent ones.

重要的是我们要分享自己的错误，以便其他人可以从中学习，并可能对自己的错误感到更舒服。所以这是我最近的几个。

为什么会有那么多下降的生产数据库？ (Why So Many Dropped Production Databases?)

A few months ago, there was the post on Reddit of an entry level developer who deleted the production database on his first day. We all cringe reading stories like this of those who make those big, unforgettable mistakes. We realize it wouldn’t take much for that to be us—most have had close calls.

几个月前， Reddit上有一个入门级开发人员的帖子，他在第一天就删除了生产数据库。我们都喜欢阅读那些犯下那些重大而难忘的错误的故事。我们意识到，成为我们并不需要太多，大多数人都亲密无间。

In my first job, a senior database administrator dropped the production database on his first day. These stories are everywhere. The team restored his mistake from a week old backup and kept him around. Ten years later they still poked fun at him for it.

在我的第一份工作中，一位高级数据库管理员在第一天就删除了生产数据库。这些故事无处不在。团队从一个星期大的备份中恢复了他的错误，并将他留在了身边。十年后，他们仍然为此取笑他。

One morning earlier this year I was called on to look into a production problem for a client. They were beginning to beta test their site with a small audience when overnight their site’s homepage didn’t have anything on it. I wondered if there was a bug or vulnerability that led to this.

今年早些时候的一个早晨，我被要求为客户解决生产问题。当他们的网站主页上没有任何内容时，他们开始对一小部分用户进行Beta测试。我想知道是否有导致此的错误或漏洞。

I signed in to the production machine and pulled up the database. The articles table was empty. OK, that confirmed what we were seeing on the website.

我登录到生产计算机并拉出数据库。文章表为空。好的，这证实了我们在网站上看到的内容。

The users table still had users. Weird. So we lost all our articles but at least their beta users still had their accounts. We could explain that it’s a beta and these things happen.

用户表仍然有用户。奇怪的。因此，我们丢失了所有文章，但至少他们的Beta用户仍然拥有他们的帐户。我们可以解释说这是一个beta版本，并且发生了这些事情。

The next few moments were a blur. I don’t recall exactly what I did. I don’t think I was dumb enough to type drop table users in the console. But there I was, now with no articles and no users table. I sat there in shock for a bit.

接下来的片刻变得模糊。我不记得我到底做了什么。我认为我不足以在控制台中键入drop table users 。但是我在那里，现在没有文章，也没有用户表。我震惊地坐在那儿。

Then my mind raced on how to fix this. Did I really drop the users table? Yes. Did we run backups? No. How do we tell the client this? I don’t know.

然后我开始思考如何解决这个问题。我真的删除了用户表吗？是。我们运行备份了吗？否。我们如何告诉客户？我不知道。

I remember walking over to the project manager, sitting down next to her, and explaining what had happened. We didn’t have data in our articles table, so that’s why the site looked empty. And oh yeah, I also dropped the users table. They were now going to need to re-invite all those users—if they could figure out who they all were. Yikes.

我记得走到项目经理那里，坐在她旁边，解释发生了什么。我们的文章表中没有数据，因此这是该网站看起来空的原因。哦，是的，我也删除了用户表。现在，他们需要重新邀请所有这些用户(如果他们可以弄清楚他们是谁)。 kes

I went back to my desk feeling defeated.

我回到办公桌前感到沮丧。

Something didn’t sit right with me, though. How did we lose all those articles in the first place?

但是，有些事情与我不对。 我们是如何首先丢掉所有这些文章的？

I kept digging. Part denial, part wanting to save face. Shortly afterwards, I noticed something important.

我一直在挖。部分拒绝，部分希望节省面子。此后不久，我注意到了一些重要的事情。

There were five other databases on the server. One of them had a name similar to the database I had just been looking at.

服务器上还有其他五个数据库。其中一个的名称类似于我刚刚查看的数据库。

When I checked it out, all the articles were there. The users table was fine. It turns out a configuration change had inadvertently made it to production, causing the site to point to a brand new database. Those users I saw? Seed data.

当我检查出来时，所有的文章都在那里。用户表很好。事实证明，配置更改已无意间将其投入生产，从而导致该站点指向全新的数据库。我看到的那些用户？种子数据。

What a relief! A morning of nerves and stomach acid making me feel sick, but we were able to “recover” all the data and I had found the real issue before we were to communicate the bad news.

终于解脱了！紧张的早晨和胃酸使我感到恶心，但是我们能够“恢复”所有数据，在我们传达坏消息之前，我已经找到了真正的问题。

Lots of lessons learned from the episode. One of the simplest: now we always do backups… perhaps a developer’s most effective antacid.

从这一集中学到了很多教训。最简单的方法之一：现在我们总是进行备份……也许是开发人员最有效的抗酸剂。

冲而永不超越 (Rushing And Never Getting Ahead)

One of my other recent mistakes that stands out wasn’t near as dramatic. In fact, it was tiny mistake after tiny mistake that led to a mess in the end.

我最近突出的其他错误之一没有那么严重。实际上，这是一个小小的错误，一次又一次的小错误最终导致了混乱。

Our challenge was a project on a tight timeline. (Aren’t they all, though?)

我们面临的挑战是时间紧迫的项目。 (不是全部吗？)

In our first meeting, we agreed as a team this would take twice the time we had. With the deadline bearing down on us from the very beginning, I breezed through the authentication piece so we could move on to the functionality the client really cared about.

在我们的第一次会议上，我们作为一个团队同意这将花费我们两倍的时间。由于截止日期从一开始就迫在眉睫，所以我轻而易举地通过了身份验证，因此我们可以继续进行客户真正关心的功能。

I had only implemented authentication once before in a single page app and still didn’t fully understand how it was supposed to fit together.

我以前只在一个页面应用程序中实施过一次身份验证，但仍然不完全了解它应该如何组合在一起。

What a mistake to hack it out as fast as I could. I missed a few important things:

尽可能快地破解它是一个错误。 我错过了一些重要的事情：

The user loaded from a cookie after sign in, but the page tried to load without waiting. Depending on the order of these events, you’d get responses from the server saying you were unauthorized. The error was rare and tough to reproduce because most of the time, things completed in the right order.
用户登录后从Cookie加载，但是该页面尝试加载而没有等待。根据这些事件的顺序，您将从服务器收到响应，称您未经授权。该错误很少发生并且很难重现，因为在大多数情况下，事情都是按正确的顺序完成的。
The authentication also never checked whether the token had expired. If you didn’t visit the site often, when you’d return the site wouldn’t work and you’d have to sign out and sign back in.
身份验证也从未检查过令牌是否已过期。如果您不经常访问该站点，那么当您返回站点时将无法正常工作，因此您必须先注销然后重新登录。
The token was supposed to update with every request, but I never had the time to understand the rules around it. So this once again produced a timing issue. If we sent several requests at the same time, depending on the order they returned you’d get the wrong token being used in future requests.
该令牌应该随每个请求进行更新，但是我从来没有时间去了解它的规则。因此，这再次产生了时间问题。如果我们同时发送多个请求，则根据它们返回的顺序，您会在以后的请求中使用错误的令牌。

We rushed and we still ended up taking twice the time given. The difference was many more bugs, and then spending even more time tracking down and fixing those bugs.

我们赶时间，但最终还是花了两倍的时间。区别在于有更多的错误，然后花费更多的时间来跟踪和修复这些错误。

My work embarrassed me. Then being shamed in public for it made the whole experience that much worse.

我的工作使我感到尴尬。然后因为在公众场合受到羞辱而使整个体验变得更加糟糕。

I will say one thing: since then, I took the time to learn authentication. I now understand OAuth, JWT, refresh tokens, and expirations. I pored over authentication code others had written in a number of libraries. I built authentication flows in a few different languages and frameworks.

我会说一件事：从那以后，我花时间学习认证。现在，我了解了OAuth，JWT，刷新令牌和有效期。我仔细研究了其他人在许多库中编写的身份验证代码。我用几种不同的语言和框架构建了身份验证流程。

将失败转化为未来的成功 (Turning Failures into Future Successes)

That’s the one thing I take away from everything that goes bad. Almost always something good comes from it if you will it.

那是我摆脱一切不幸的一件事。如果您愿意的话，几乎总是从中得到好处。

If someone learns from their mistake, they are now better than they were before. I try not to get down on a teammate who makes a mistake the first time. They usually already know they messed up.

如果有人从错误中吸取教训，那么他们现在会比以前更好。我尽量不让第一次犯错误的队友失望。他们通常已经知道自己搞砸了。

I’m working on not being so hard to those who repeat the same mistake over and over, though. They still deserve compassion.

但是，我正在努力不让那些一遍又一遍重复相同错误的人变得如此努力。他们仍然值得同情。

You’ll continuously grow if you can do four things with mistakes:

如果您能做四件事有错误，就会不断成长：

laugh at having made one
嘲笑自己做了一个
learn from it
从中学习
destigmatize making them
贬低他们
and share your mistake so others can benefit from it, too
并分享您的错误，以便其他人也可以从中受益

I’ll leave you with a final anecdote about the value of mistakes. IBM’s CEO during the early 1900s, Thomas J Watson, once encountered an employee whose series of bad decisions cost the company greatly. When asked whether Watson was going to fire this employee, Watson responded:

我将为您提供关于错误价值的最后轶事。 1900年代初期，IBM的首席执行官Thomas J Watson曾经遇到过一名雇员，其一系列的错误决定使公司付出了巨大代价。当被问及沃森是否要解雇该雇员时，沃森回答：

“No, I just spent $600,000 training him. Why would I want somebody to hire his experience?”

“不，我刚刚花了60万美元训练他。我为什么要有人雇用他的经验？”

Have an interesting mistake in your past? Share it!

您过去有过有趣的错误吗？分享它！

Thank you for reading the article! If you find it helpful and would like to show your support, then please share it and be sure to hit that ? button. For more articles like this, follow the publication and the author on Twitter.

感谢您阅读本文！如果您觉得它有帮助并希望显示您的支持，请与我们分享并确保实现目标？按钮。有关更多此类文章，请关注其出版物以及在Twitter上的作者。

Zach Kuhn is a Director of Development at Smashing Boxes, a Durham, N.C.-based digital agency. He has built web and mobile apps for over a decade, and is involved with startups and emerging technologies like blockchain, IoT, and machine learning.

Zach Kuhn 是位于北卡罗来纳州达勒姆的数字代理商Smashing Boxes的开发总监。 他已经建立了Web和移动应用程序超过十年，并参与了初创公司和新兴技术，如区块链，物联网和机器学习。