秘密潛入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.

今年早些時候的一個早晨，我被要求為客戶解決生產問題。 當他們的網站主頁上沒有任何內容時，他們開始對一小部分用戶進行B??eta測試。 我想知道是否有導致此的錯誤或漏洞。

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和移動應用程序超過十年，并參與了初創公司和新興技術，如區塊鏈，物聯網和機器學習。

翻譯自: https://www.freecodecamp.org/news/the-times-ive-messed-up-as-a-developer-3c0bcaa1afd6/

秘密潛入2小辣椒

總結

以上是生活随笔為你收集整理的秘密潜入2小辣椒_短暂潜入2次，我显然不知道自己作为开发人员正在做什么的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。