Experience is the hardest kind of teacher. It gives you the test first and the lesson afterward. This quote from Oscar Wilde sums up the life of an inexperienced programmer pretty well.

经验是最难的老师。 它首先给您测试，然后给您上课。 奥斯卡·王尔德(Oscar Wilde)的这段话很好地总结了一个没有经验的程序员的生活。

You learn by doing. Getting your hands dirty. And in the process of doing you’ll make mistakes which is totally fine as long as you learn from your mistakes. That’s how you gain experience.

你边做边学。 让您的手变脏。 在这样做的过程中，只要您从错误中学习，就会犯错，这是完全可以的。 那就是您获得经验的方式。

As an inexperienced developer, you’ll get these kinds of tests on a daily basis. But how do you recognize an inexperienced developer? Here are four signs that show you some of the characteristics of an inexperienced developer.

作为一个没有经验的开发人员，您将每天获得这些测试。 但是，您如何识别经验不足的开发人员？ 这是四个迹象，向您展示经验不足的开发人员的一些特征。

It is costly wisdom that is bought by experience — Roger Ascham

经验可以买到昂贵的智慧—罗杰·阿瑟姆(Roger Ascham)

非结构化代码 (Unstructured code)

Writing unstructured code is what you expect from an inexperienced developer. If it’s slightly structured that’s already a big win. The reason inexperienced developers write unstructured code is that their focus is heavily on getting it to work. More experienced developers know that there’s more to being a developer.

经验不足的开发人员希望编写非结构化代码。 如果结构略微，那已经是一个很大的胜利。 缺乏经验的开发人员编写非结构化代码的原因是，他们的精力主要集中在使它起作用。 更有经验的开发人员知道，成为一名开发人员还有更多。

Writing code and getting it to work is such a tiny part of your job as a developer. Although, inexperienced developers think it’s the biggest part of their job. As you get more experienced, you’ll realize most of your job consists of maintaining projects instead of building new projects from scratch.

作为开发人员，编写代码并使之正常工作是您工作的一小部分。 虽然，没有经验的开发人员认为这是他们工作的最大部分。 随着经验的积累，您将意识到大部分工作是维护项目，而不是从头开始构建新项目。

Once you start realizing this, you’ll code in a whole different way. You start coding in a way that makes your code more maintainable and easy to understand for other developers.

一旦开始意识到这一点，您将以完全不同的方式进行编码。 您以一种使您的代码对其他开发人员更易于维护和易于理解的方式开始编码。

Failing to realize this will lead to things like functions with the size of an essay. This comes which has a lot of downsides — testability, for example. How can you test a function that does five different things and has the size of an essay?

未能意识到这一点将导致诸如论文之类的功能。 这带来了很多缺点-例如可测试性。 如何测试具有五种不同功能并且具有论文大小的函数？

When the goal is to just make it work the problem is that most of the time the code isn’t well-thought-out. The quality of the code suffers from this. This type of code often looks like procedural code that doesn’t stick to coding principles like the Single Responsibility Principle. Once code like this enters the maintenance phase you start to feel the lack of quality of the code.

当目标是使其正常工作时，问题是大多数时候代码都没有被深思熟虑。 代码的质量因此而受到影响。 这种类型的代码通常看起来像过程代码，并不遵循诸如单一职责原则之类的编码原则。 一旦这样的代码进入维护阶段，您就会开始感到代码质量不足。

gun弹枪调试 (Shotgun debugging)

BANG!

砰！

Okay, that didn’t work.

好吧，那没有用。

BANG!

砰！

Okay, that didn’t work either.

好的，那也不起作用。

When inexperienced developers run into a problem they most often start shotgun debugging — they randomly change some stuff in the code in the hope it fixes their problem without knowing what the actual problem is.

当经验不足的开发人员遇到问题时，他们通常会开始进行shot弹枪调试-他们随机更改代码中的某些内容，以希望在不知道实际问题是什么的情况下解决问题。

This doesn’t work most of the time, obviously. Chances are by making these random changes you’ll only introduce more bugs. What you should do, instead of shotgun debugging, is to gather more information regarding the problem.

显然，这在大多数时候都不起作用。 通过随机更改，您只会引入更多错误。 您应该做的是收集有关该问题的更多信息，而不是shot弹枪调试。

There are way better approaches when it comes to debugging your code. The first thing you want to do is find out how you can reproduce the problem. Make sure you know how to do this before you start applying any changes to your code.

有一些更好的方法来调试代码。 您要做的第一件事是找出如何重现该问题。 在开始对代码进行任何更改之前，请确保您知道如何执行此操作。

Opening the log files (hopefully you have any) can be a good start of your debug journey. See whether you can find some useful information that can lead you in the right direction. It’s important to gather information before you start changing the code, so you have an understanding of what’s actually causing the bug.

打开日志文件(希望有日志文件)可以是调试过程的一个良好的开始。 看看您是否能找到一些有用的信息，这些信息可以引导您朝正确的方向发展。 在开始更改代码之前收集信息非常重要，这样您就可以了解导致错误的真正原因。

Once you’ve found the cause of the bug and fixed it you’re not done yet. If you really want to do things well you should write at least one test for your fix. This way you’re covered when things go south in the future.

一旦找到了错误的原因并解决了，您还没有完成。 如果您确实想做得好，则应该至少编写一个测试来解决问题。 这样一来，将来一切都变南时，您就可以得到覆盖。

过于关注技术 (Too much focus on the tech)

Inexperienced developers are still learning their craft. Therefore their focus is mainly on becoming a master of their tech stack. This makes sense because if you want to become a great developer you need to master your tech stack. But there’s more than just the tech that you should focus on.

没有经验的开发人员仍在学习技巧。 因此，他们的重点主要是成为技术堆栈的主人。 这是有道理的，因为如果您想成为一名出色的开发人员，则需要掌握您的技术堆栈。 但是，您不仅应该关注技术。

When learning all the ins and outs of the tech stack you shouldn’t lose the business out of sight. That’s why you’re here in the first place. It’s the reason you have this job.

在学习技术堆栈的所有内容时，您不应失去业务。 这就是为什么您首先在这里。 这就是你有这份工作的原因。

Is what you’re working on creating value for the business or are you spending too much time on something that’s irrelevant to the business? This is an important question you should ask yourself all the time.

您是在努力为企业创造价值，还是在与企业无关的事情上花费过多的时间？ 这是一个重要的问题，您应该一直问自己。

Being a developer comes with more than just being interested in the technical aspects of the job. Keep in mind that the business and economic factors are the factors that justify your job’s existence.

成为开发人员不仅仅对工作的技术方面感兴趣。 请记住，商业和经济因素是证明工作存在的因素。

有点不同 (A little different)

When working in a team you can sniff out the inexperienced developer by doing things a little different than the rest of the team. Inexperienced developers tend to do things their way rather than the same way as everyone else.

在团队中工作时，您可以通过做一些与团队其他成员略有不同的事情来嗅探缺乏经验的开发人员。 没有经验的开发人员倾向于以自己的方式来做事情，而不是像其他所有人一样。

Sometimes this happens unintentionally. The inexperienced fails to recognize certain patterns in solutions. If this sounds familiar to you, there is something you could do might help you in the future.

有时这是无意发生的。 没有经验的人无法识别解决方案中的某些模式。 如果您觉得这很熟悉，那么您将来可能会做些事情。

In order to do things in the same way as everyone else in the team, you could take a look at all the pull requests that get created. You don’t have to review all of them, but just make sure you take a look at how other developers solve certain problems. Is their solution similar to the way you would fix the problem? If not, ask why they went for their solution and if they considered your solution.

为了以与团队中其他所有人相同的方式执行任务，您可以查看所有创建的拉取请求。 您无需复习所有内容，只需确保您看看其他开发人员如何解决某些问题即可。 他们的解决方案是否类似于您解决问题的方式？ 如果不是，请询问他们为何寻求解决方案，以及他们是否考虑了您的解决方案。

升级编码 (Level Up Coding)

Thanks for being a part of our community! Subscribe to our YouTube channel or join the Skilled.dev coding interview course.

感谢您加入我们的社区！ 订阅我们的YouTube频道或参加Skilled.dev编码面试课程 。