良好的编码本能最终会让您大吃一惊

I wrote my first few lines of code almost 32 years ago, when I was 6 years old. I developed very strong coding instincts. I could look at any problem and immediately know how to solve it, just by intuition.

我大约32年前(当时我6岁)编写了我的前几行代码。 我发展了非常强烈的编码本能。 我可以凭直觉看到任何问题并立即知道如何解决。

By the time I started coding the web for a living, I felt like a rock star. I found and fixed bugs faster than any of my co-workers. My team started assigning me all the most challenging features and the most nagging bugs. They even started calling me a “wizard.”

当我开始为生活编写网络代码时，我感觉自己像个摇滚明星。 与所有同事相比，我发现和修复错误的速度更快。 我的团队开始为我分配所有最具挑战性的功能和最棘手的错误。 他们甚至开始称我为“向导”。

But following your intuition can only take you so far. I hit a plateau. And no amount of coding instinct was going to push me past it.

但是遵循您的直觉只能使您走得更远。 我达到了高原。 而且没有多少编码本能使我超越它。

相信自己的直觉会带来麻烦 (The trouble with trusting your gut)

Unfortunately, intuition as a technique for learning and problem solving doesn’t scale very well. When you rely on instinct and intuition alone, you get a curve that looks like this:

不幸的是，直觉作为一种学习和解决问题的技术并不能很好地扩展。 当您仅依靠本能和直觉时，您将得到如下所示的曲线：

Of course, you can choose to accept your limits and only ever deal with problems below the line. This will indulge your “rock star coder” fantasy, but it will quickly begin to limit your growth and your career. Plus, it’s boring.

当然，您可以选择接受您的限制，并且只能处理线下的问题。 这会让您沉迷于“摇滚歌手”的幻想，但很快就会开始限制您的成长和职业生涯。 另外，这很无聊。

As I pushed myself further and further ahead in my career — and started to really challenge my own abilities — I began to notice a disturbing trend. I was no longer the fastest kid on the block.

当我在职业生涯中不断前进，并开始真正挑战自己的能力时，我开始注意到一种令人不安的趋势。 我不再是街上最快的孩子。

I had always known that I’d eventually run into people smarter and more talented than me. (My delusions of grandeur were still grounded in reality. I’m no genius.)

我一直都知道，我最终会遇到比我更聪明，更有才华的人。 (我对宏伟的幻想仍然基于现实。我不是天才。)

But when I looked around, I realized that some of the people beating me were not using a superior intellect or some sort of innate gift for code. They just had a secret weapon that I sorely lacked: discipline.

但是当我环顾四周时，我意识到有些殴打我的人并没有使用高超的智力或某种先天的礼物作为代码。 他们只是拥有我非常缺乏的秘密武器： 纪律 。

It turns out that a consistent, repeatable, methodical approach to learning and problem solving will eventually outperform any natural gifts — or instincts — that you may have developed.

事实证明，一种一致，可重复，有条不紊的学习和解决问题的方法最终将胜过您可能已经开发出的任何自然天赋或直觉。

让我们提高解决问题的能力 (Let’s tool up those problem solving abilities)

Regardless of who you are, how much passion or natural talent you have, you will eventually hit a hard ceiling. I’m going to share with you a few techniques that will dramatically improve your disciplined problem solving abilities.

不管您是谁，拥有多少热情或天赋，最终您都将面临困难。 我将与您分享一些技巧，这些技巧将大大提高您训练有素的问题解决能力。

I’m assuming that, if you have a debugger, you’ve already run it, Googled the output, and had no luck.

我假设，如果您有调试器，那么您已经运行了它，对输出进行了Google搜索，并且没有运气。

I’m also assuming that if the problem was reported by someone else, you have been able to reproduce the problem. This second assumption is a big one. If you can’t reproduce the problem, then that needs to be your first step.

我还假设如果问题是由其他人报告的，则您已经能够重现该问题。 第二个假设很重要。 如果您无法重现该问题，那么这就是您的第一步。

You need to compare the context and environment in which the problem occurred to the context and environment in which you are trying to reproduce it. Start eliminating any differences you can, one by one, until you can reproduce.

您需要将问题发生的环境和环境与试图重现该问题的环境和环境进行比较。 开始消除可能出现的任何差异，直到可以复制为止。

Once you can reproduce the problem, and after the debugger has failed to be of any use, you can try the following disciplined approaches.

一旦可以重现该问题，并且在调试器无法使用后，您可以尝试以下严格的方法。

实时FM (RTFM)

Read the documentation, you fool! (Admittedly this isn’t what RTFM stands for exactly, but there may be children reading.)

阅读文档，傻瓜！ (诚​​然，这并不是RTFM确切代表的意思，但是可能会有孩子在读书。)

Actually read it — more than once if you need to. Don’t just skim it looking for something you can copy, paste, and pray will work.

实际阅读 -如果需要，可以多次阅读 。 不要只是浏览它，寻找可以复制，粘贴并祈祷能工作的东西。

The problem is you want an answer fast. You want that thrill of victory. But you’re not willing to put in the work. So slow down. Take a breath. Grab a coffee. And read the relevant documentation all the way through.

问题是您想要快速回答。 您想要胜利的快感。 但是您不愿意投入工作。 慢点 喘口气。 喝杯咖啡。 并完整阅读相关文档。

If you have no documentation, consider creating some, then sharing it with others after you’ve fixed the problem.

如果没有文档，请考虑创建一些文档，然后在解决问题后与其他人员共享。

测试你的假设 (Test Your Assumptions)

If you expect something to work and it doesn’t, it’s because you’ve made a bad assumption somewhere along the way. Take an inventory of your assumptions and try to prove that each one is true.

如果您希望某些东西行得通而没有用，那是因为您在此过程中的某个地方做出了错误的假设。 盘点您的假设，并尝试证明每个假设都是正确的。

Start with the most basic assumptions that can be quickly tested. Is the server actually running? Is it connected to the network? Is everything spelled correctly? Are all the brackets and semicolons in the right place?

从可以快速检验的最基本的假设开始。 服务器实际上在运行吗？ 它连接到网络了吗？ 一切拼写正确吗？ 所有括号和分号是否都位于正确的位置？

If you don’t start with the simple things, and it does turn out to be one of these things, when you finally figure it out you will want to jump out a window. So save yourself the headache.

如果您不是从简单的事情开始，而事实确实是其中之一，那么当您最终弄清楚它时，您将希望跳出一个窗口。 因此，省去您的头痛。

拆卸和重新组装 (Disassemble and Reassemble)

Remove components from the solution until it starts working again, then put the components back one-by-one in order to find the broken piece.

从解决方案中取出组件，直到它再次开始工作，然后将组件一一放回以找到损坏的部件。

This feels tedious and scary, but it is one of the most effective, disciplined ways to find the cause of a bug in your code. Make sure you have a backup before you start though, in case you accidentally end up with Humpty Dumpty code (code that you can’t put back together again).

这让人感到乏味且令人恐惧，但这是在代码中查找错误原因的最有效，纪律严明的方法之一。 不过，请确保在开始之前已备份，以防万一意外导致出现“矮胖”代码(无法再次组合在一起的代码)。

By the way, if you find yourself in a situation where you don’t know how to reassemble the code back to how it was, this is an indication of a potentially bigger problem: you don’t understand the codebase you’re working with. That’s bad bananas, my friend.

顺便说一句，如果您发现自己不知道如何将代码重新组装回原来的状态，则表明存在潜在的更大问题：您不了解所使用的代码库。 我的朋友，那是坏香蕉。

If you’re on a tight deadline, seek help immediately from someone who understands the codebase better than you. If no such person exists, dig in for a long night, and prioritize getting to know and understand how this code works, so that you can fix it.

如果您的期限很紧迫，请立即向比您更了解代码库的人寻求帮助。 如果没有这样的人，请花一整夜的时间，优先了解和理解此代码的工作原理，以便您进行修复。

消除变量 (Eliminate Variables)

Anything that can change from one trial to the next should be made to remain static while you’re debugging. You can’t hit a moving target. This is where Test Driven Development (TDD) comes in handy. If you’re using TDD, then you should have some mock objects at your disposal.

从调试到下一个的任何更改都应在调试时保持不变。 您无法击中目标。 这就是测试驱动开发(TDD)派上用场的地方。 如果使用的是TDD，则应使用一些模拟对象。

Mock objects are simulated objects that mimic the behavior of real objects in controlled ways. A programmer typically creates a mock object to test the behavior of some other object, in much the same way that a car designer uses a crash test dummy to simulate the dynamic behavior of a human in vehicle impacts. — Wikipedia

模拟对象是模拟对象，它们以受控方式模仿实际对象的行为。 程序员通常会创建一个模拟对象来测试其他对象的行为，这与汽车设计师使用碰撞测试假人来模拟人在车辆撞击中的动态行为时非常相似。 — 维基百科

If you didn’t do TDD, then you’ll need to mock out any moving parts now, so that you can find the bug under stable conditions.

如果您没有执行TDD，那么您现在需要模拟所有活动部件，以便可以在稳定的条件下找到该错误。

Here’s a tip: if you mock an object and the bug suddenly goes away, then the bug is likely in the object you mocked.

这里有个提示：如果您模拟一个对象而该错误突然消失，则该错误很可能出现在您模拟的对象中。

使用“ Saff Squeeze” (Use the “Saff Squeeze”)

There’s a technique called the “Saff Squeeze” — named and popularized by Kent Beck — that is sort of a cross between the two ideas above.

有一种称为“ Saff Squeeze”的技术(由Kent Beck命名并推广)，是上述两种想法之间的一种交叉。

He describes it this way:

他这样描述：

“To effectively isolate a defect, start with a system-level test and progressively inline and prune until you have the smallest possible test that demonstrates the defect.” — Kent Beck

“要有效地隔离缺陷，请从系统级测试开始，逐步进行内联和修剪，直到您能证明缺陷的最小测试为止。” 肯特·贝克

So instead of formal mocks or code disassembly, you simply add the body of the functions that you’re testing into the test itself, then move the assertions down until the bug goes away.

因此，您只需将要测试的函数主体添加到测试本身中，而不用进行正式的模拟或代码反汇编，然后向下移动断言，直到错误消失。

This has the added benefit of leaving you with smaller, more specific tests.

这样做还有一个好处，那就是让您进行更小巧，更具体的测试。

Edit: Thanks to Jim Balter for pointing out this link to a good example and explanation of the Saff Squeeze.

编辑 ：感谢吉姆·巴尔特 ( Jim Balter)指出此链接到Saff Squeeze的一个很好的例子和解释。

修复后，将其破坏并再次修复 (After You Fix It, Break It and Fix It Again)

Never leave a bug until you fully understand how you fixed it. You should be able to reproduce the bug and fix it again at will.

在完全了解如何解决错误之前，切勿留下错误。 您应该能够重现该错误，然后再次对其进行修复。

I can’t stress this enough. If you fix a bug and you’re not sure exactly what caused it or how you managed to fix it, that bug will come back to bite you at the worst possible time.

我不能太强调这一点。 如果您修复了某个错误，但不确定是什么原因导致的错误，或者不确定如何修复，那么该错误会在最糟糕的时间再次叮咬您。

那这些本能呢？ (What About Those Instincts?)

Now that you’ve learned these techniques, does that mean you should always use them first instead of relying on your instincts? No. Absolutely not.

现在，您已经学会了这些技术，这是否意味着您应该始终首先使用它们，而不要依赖于您的直觉？ 不，绝对不会。

What I recommend is that you give your instincts a time box in which to succeed. If you have a strong hunch about what the problem might be — and you can test your hunch quickly — do that first. If the bug is below the green line in the chart above, chances are that your instincts will be the fastest path to a solution.

我建议您给直觉一个成功的时机。 如果您对可能的问题有很强的预感，并且可以快速测试一下预感，请首先执行此操作。 如果该错误位于上图中的绿线下方，则很可能您的直觉将是解决方案的最快途径。

Once you’ve quickly tried your first or second hunch and been wrong though, stop the shotgun approach and start doing things methodically.

一旦您快速尝试了第一次或第二次预感，但又错了，请停止the弹枪方法并有条不紊地开始工作。

Having both instincts and discipline will make you one of the top coders on any team.

具有直觉和纪律，将使您成为任何团队中顶级的编码人员之一。

If you liked this piece, please ❤ recommend ❤ and share it. I’d like to help as many developers as I can.

如果您喜欢此作品，请❤推荐❤并分享。 我想为尽可能多的开发人员提供帮助。

To help you even more, I have put together a free PDF list of my five favourite code refactoring techniques — that lead to fewer bugs — get it by clicking here.

为了给您更多帮助，我整理了一份免费的 PDF清单，其中列出了我最喜欢的五种代码重构技术(可减少错误)， 请单击此处。

翻译自: https://www.freecodecamp.org/news/good-coding-instincts-will-eventually-kick-you-in-the-teeth-2b3766897f3f/