乐高ev3涉及到的一些赛事_使您成为英雄的前五名开发者技能（提示：涉及LEGO）

最新推荐文章于 2024-10-02 10:53:34 发布

cumi7754

最新推荐文章于 2024-10-02 10:53:34 发布

阅读量2k

点赞数

文章标签： python 人工智能 java 大数据编程语言

原文链接：https://www.freecodecamp.org/news/the-hero-developer-who-knew-how-to-build-lego-bricks/

版权

乐高ev3涉及到的一些赛事

Programming is like building something with LEGOs. Any developer can pick up a brand new LEGO set and build it following the instructions. This is very easy. Think of it as coding school assignments or entry level tutorials.

编程就像用乐高积木一样。任何开发人员都可以选择全新的LEGO集并按照说明进行构建。这很容易。可以将其视为编写学校作业或入门级教程的代码。

A real software project is different. It is like building a very large castle set. Except it has already been built in the past. Then someone torn it to pieces with a savage kick. The bigger parts remain kind of together. But the smaller parts were completely crushed. Some elements went out the window.

真正的软件项目是不同的。这就像建造一个非常大的城堡。除了过去已经建造过。然后有人用野蛮的脚把它撕成碎片。较大的部分仍然保持在一起。但是较小的部分被完全压碎了。一些元素消失在窗外。

You get a box containing what's left, but also thousands of pieces from other sets. And the instructions are gone, of course. You can only rely on one picture to know what the castle looks like.

您会得到一个盒子，里面装有剩下的东西，还有数千套其他物品。当然，指示也消失了。您只能依靠一张照片来了解城堡的外观。

Now that's interesting! Let's see what we can do to work effectively in such an environment.

现在很有趣！让我们看看如何在这种环境下有效工作。

1.接受未知 (1. Accept the unknowns)

The first step of any development task is to understand what you need to do. It sounds obvious. And yet, the bigger the task, the more unknown variables you get. This is the moment to set clear expectations.

任何开发任务的第一步都是了解您需要做什么。听起来很明显。但是，任务越大，您获得的未知变量就越多。这是树立明确期望的时刻。

If you have no clue how to get started, there is no point thinking and conceptualizing too long. Start and get your head around the key elements you need. Then think again. If anyone asks you for estimates or a deadline upfront, be open and honest. Some parts of the system you don't know or may not understand. And that's OK.

如果您不知道如何入门，那么思考和概念化的时间就太长了。开始并掌握所需的关键要素。然后再想一想。如果有人要求您提前估计或截止日期，请保持坦诚。您不了解或可能不了解的系统某些部分。没关系。

Think of platforms like Facebook, Netflix or Oracle. Or any larger enterprise software out there. Very few people can grasp the full scope. The ones who do have either built it or spent years working with it. So first of all, give yourself a break for not knowing everything. And more importantly, accept that you won't know everything.

想想诸如Facebook，Netflix或Oracle之类的平台。或任何更大的企业软件。很少有人能够掌握全部范围。确实已经构建或花费了数年时间的人们。因此，首先，让自己休息一下，不要一无所知。更重要的是，接受您不会一无所知。

Experienced and productive developers are not better coders. They are better at evaluating what they need to do. And at picking the right strategies to cope with the unknowns.

经验丰富，生产能力强的开发人员不是更好的程序员。 他们更擅长评估他们需要做什么。 并选择正确的策略来应对未知数。

LEGO analogy: Think of the castle set we want to rebuild. Say someone gives you a picture of the castle and the box, and asks you "how much time do you need to build the castle?" There is no good answer to that except "I don't know yet. Let me start and let's see where I am at after a day or two".

乐高类比 ：想想我们要重建的城堡。假设有人给您一张城堡和盒子的图片，然后问您“建造城堡需要多少时间？” 除了“我还不知道。让我开始看一两天后我在哪儿”，对此没有好的答案。

The ultimate "I fear the unknowns" approach to this task would be to lay out all the elements from the box on the floor. Try to separate them into the sets they belong to based on color and shape. Then look at the picture and make a mental map on how to assemble the bricks.

最终的“我害怕未知数”方法是将所有元素从地板上的盒子中放出来。尝试根据颜色和形状将它们分成所属的组。然后看图片，并就如何组装积木制作一张心理图。

This approach is not very effective for two reasons. First, if the castle is too big you'll probably never get there. Second and most important: you can't assess progress. You could be on the right track or not at all. You have no feedback loop.

这种方法不是很有效，原因有两个。首先，如果城堡太大，您可能永远都无法到达那里。第二个也是最重要的：您无法评估进度。您可能走在正确的轨道上，或者根本不走。您没有反馈回路。

Another approach would be to start building the castle. As you go you will learn if it is easy to find the pieces you need or not. You will know if the picture shows all the details or if the construction is more complex than it looks.

另一种方法是开始建造城堡。在您进行时，您将了解是否容易找到所需的零件。您将知道图片是否显示了所有细节，或者结构是否比看起来复杂。

Based on this information you'll be able to make a more educated guess on the time and effort it will take to do the job. And if it's worth doing at all.

根据这些信息，您可以对完成这项工作所需的时间和精力做出更有根据的猜测。如果值得一做。

If you need it built for tomorrow morning, maybe going to the store and buying the same castle again is a better solution? That's might not be your decision to make, but solutions to a problem does not always come through more code.

如果您需要明天早上建造的城堡，也许去商店再买同一座城堡是更好的解决方案？这可能不是您的决定，但是解决问题并不总是通过更多的代码来完成。

2. 接受妥协 (2. Accept compromise)

Developers often praise and value "great attention to details". Every job offer out there has this in one form or the other. That's all good. But don't confuse attention to details with stubbornness and perfectionism.

开发人员经常称赞和重视“对细节的高度关注”。那里的每个工作机会都以一种形式或另一种形式存在。很好但是，不要将对细节的关注与固执和完美主义相混淆。

When starting a big task you have to define two versions of it. The first version is the bare minimum you need to verify that things will work the way you think they will.

启动大任务时，必须定义它的两个版本。第一个版本是您需要验证事物是否按照您认为的方式工作的最低要求。

That's what I call "working horizontally". Each piece of your bigger task is a vertical. You don't have to go deep to get the first results. Focus on the main use case or scenario first. And take it from there.

这就是我所说的“水平工作”。您的较大任务的每一项都是垂直的。您无需深入研究即可获得第一个结果。首先关注主要用例或方案。并从那里拿走。

The things you can leave behind in the first version:

您可以在第一个版本中留下的东西：

error handling
错误处理
edge cases
边缘情况
clean code
干净的代码
configuration
组态

Don't think of all that and just write the code you need as it flows from your fingers. You should get to a high functional coverage quickly. Sure, it will take a lot of time to move from this first, simplistic version to the final one. So what is the point?

不用考虑所有这些，只需编写所需的代码即可。您应该Swift获得较高的功能覆盖率。当然，从第一个简单的版本过渡到最后一个版本将花费很多时间。那有什么意义呢？

That's a safer way to progress. You want to verify your assumptions. As smart and capable as you may be, designing and conceptualizing can only take you so far. Get your hands dirty. It will give you more knowledge and insight than any "thinking it through".

这是一种更安全的进步方式。您想验证您的假设。设计和概念化虽然像您一样聪明又有能力，只能带您走远。弄脏你的手。它比任何“思考”方式都给您更多的知识和见识。

This is the same principle that applies to MVPs for new products or features in business. The approach also has the advantage that you can show your first version and get feedback. Or ask questions. It's easier to brainstorm on existing code than on a drawing or concept.

这与适用于业务中新产品或功能的MVP的原理相同。该方法还具有可以显示您的第一个版本并获得反馈的优点。或问问题。在现有代码上集思广益比在图形或概念上集思广益。

LEGO analogy: You are building the tower of the castle. On the picture the high tower walls are made of interlaced grey and white bricks. There is a princess locked in the tower and a dragon on the roof.

乐高类比：您正在建造城堡塔。在图片上，高塔墙由交错的灰色和白色砖砌而成。塔中有一位公主，屋顶上有一条巨龙。

You find the princess and the dragon but it would take you ages to find the grey and white bricks you need. The right approach is to build the wall using any bricks, and place the princess and the dragon. You can leave a TODO like "Improve the bricks of the wall".

您会找到公主和巨龙，但是要找到所需的灰色和白色砖块需要花费您很多年的时间。正确的方法是使用任何砖块建造墙，然后放置公主和龙。您可以留下“改善墙砖”之类的待办事项。

The idea is that you have identified a problem: it's going to be difficult to build the perfect wall. Let's accept that and move on to discover all the other obstacles we don't know about yet. Accepting the compromise prevents you from getting stuck.

想法是您已经确定了一个问题：建造完美的墙将很困难。让我们接受这一点，继续发现我们尚不了解的所有其他障碍。接受妥协可以防止您陷入困境。

Even if you never get to the TODO, you can tell your customer: "Here is the full castle. We know we have to improve the tower wall, but it's built". This is much better than "We are heavily delayed because it took us ages to find the right bricks for the tower. But look, the tower is perfect and exactly as on the picture you sent us. Now we'll get to the rest of the castle".

即使您从未到过TODO，也可以告诉您的客户：“这里是完整的城堡。我们知道我们必须改善塔墙，但它已经建成”。这比“由于我们花了很多年才能为塔找到合适的砖块而耽搁了很多时间要好得多。但是，看一下，塔是完美的，并且与您发送给我们的图片完全一样。现在，我们将继续其余内容城堡”。

Important: don't confuse compromise and sloppiness.

重要提示：不要混淆妥协和草率。

The key elements of the tower are the princess and the dragon. Don't put a farmer in the tower and a cat on the roof and think that's an OK compromise. It won't work :)

塔的主要元素是公主和龙。不要在塔上放一个农夫，在屋顶上放一只猫，不要以为这是个妥协。它不会工作:)

3.从外部世界开始 (3. Start with the outside world)

There are many things you can control. And things you can't. I learned that the hard way on one of my first assignments as a developer ten years ago. The task was to integrate an external API and process the data. I had one week. It was a very reasonable timeline, even for an inexperienced guy like me.

您可以控制很多事情。还有你做不到的事情。十年前，我了解到这是我作为开发人员的第一个任务时遇到的困难。任务是集成外部API并处理数据。我有一个星期。即使对于像我这样没有经验的人，这也是一个非常合理的时间表。

Here is what I did (and what you shouldn't do):

这是我所做的(以及您不应该做的)：

It's Monday morning. I've read the API documentation for 10 minutes. It seems very easy. I create a test data set and moving on to write the code to process it. I will test with the real API once I'm done.

今天是星期一早上。我已经阅读了10分钟的API文档。看起来很容易。我创建一个测试数据集，然后继续编写代码以对其进行处理。完成后，我将使用真实的API进行测试。

Wednesday morning and I'm almost done. I think my code is clean and well designed and everything (it wasn't). Now I just need to integrate the API and I'll probably finish ahead of time. I can't help but think that "I am awesome".

星期三早上，我快完成了。我认为我的代码干净，设计良好，而且一切正常(事实并非如此)。现在，我只需要集成API，就可以提前完成。我忍不住想说“我很棒”。

I quickly get to the API part. I'm trying to reach it with my code. Except I can't. Something is wrong. I waste the whole day double checking everything. Using different API clients. No progress. The day flashes and it is Wednesday evening now.

我很快进入了API部分。我正在尝试通过我的代码来达到目的。除了我不能。出了点问题。我浪费了一整天仔细检查一切。使用不同的API客户端。没有进展。那天闪烁着，现在是星期三晚上。

I am stuck, and I feel quite the opposite of awesome.

我被困住了，感觉与真棒相反。

I get to work on Thursday and ask a colleague for help. He tells me that access to the API may be IP restricted and that I have to contact the company to white-list our IPs. Good, I have a way forward.

我星期四上班，请同事帮忙。他告诉我，对API的访问可能受IP限制，因此我必须与该公司联系以将我们的IP列入白名单。好，我有前进的方向。

I send an email to the company owning the API. It's like 8AM. I foolishly expect a quick answer and resolution within minutes. I sweat all morning and at noon I finally pick up the phone and call the support number. I explain my problem and try to highlight the best I can how big an "emergency" it is (it wasn't).

我向拥有API的公司发送电子邮件。就像早上8点。我愚蠢地期望在几分钟之内得到快速答复和解决。我整个上午都出汗，中午终于拿起电话，打了支持电话。我会解释我的问题，并尽最大努力突出它的“紧急”程度(不是)。

The guy on the other side of the line explains me that the white-listing time is usually 1 or 2 days. Now I am depressed. 1 or 2 days? How is this possible? My task is the most important in the world (only to me of course) and they tell me "1 or 2 days"?

另一端的人向我解释，白名单的时间通常为1或2天。现在我很沮丧。 1或2天？这怎么可能？我的任务是世界上最重要的任务(当然，仅对我来说)，它们告诉我“ 1或2天”吗？

All of a sudden I am not ahead anymore. I am late. I failed. I go to my boss and tell him I screwed up. I should have checked the API Monday morning. I would then have requested access the same day and I would have written my code in the meantime. He just smiles back as a "Yes you should have".

突然我不再领先了。我迟到了。我失败了。我去找老板，告诉他我搞砸了。我应该在星期一早上检查一下API。然后，我将在同一天请求访问权限，与此同时，我将编写代码。他只是笑着说“是的”。

I finally get access on Friday and have to stay very late to finish the job. I adapt my code to the many surprises the API data bring. Good bye well-designed and clean code. I will justify it later saying "There was no time for that" (there was).

我终于在星期五获得访问权，并且必须待得很晚才能完成工作。我使代码适应API数据带来的许多惊喜。再见，精心设计和简洁的代码。我稍后将说“没有时间”(有)来说明这一点。

In my naïveness of the time, I felt the access thing and wrong documentation were very bad luck. Now I can tell it was business as usual.

在我幼稚的时候，我感到访问和错误的文档是非常不幸的。现在我可以说这是照常营业。

The lesson is to start with what you can't control. Confirm every assumption you have about the environment. Use manual and low cost ways to try things out as early as possible.

本课将从您无法控制的内容开始。确认您对环境的所有假设。使用手动和低成本方法尽早尝试。

LEGO analogy: Imagine you are building the castle and things are running smoothly. You now have mixed the box about 100 times looking for pieces. You can't help thinking "I never came across that huge orange dragon sitting on the tower on the picture".

乐高类比 ：想象您正在建造城堡，并且一切运行顺利。您现在已经将盒子混合了大约100次以寻找零件。您不禁会想：“我从未遇到过坐在照片塔上的那条巨大的橙色龙”。

You ignore that information to focus on the good progress you have. That's human. Moving forward is more exciting than dealing with problems. At the end you'll have to acknowledge that the dragon is missing. And tell your customer very late that the bigger piece of the set will not be present. That's not good.

您忽略了这些信息，而只关注于自己取得的良好进展。那是人类。前进比解决问题更令人兴奋。最后，您必须确认龙不见了。并非常晚地告诉您的客户，该套件中的较大部分将不存在。这不好。

The thing to do instead is to follow up on that hint: "Where is the dragon?". Spend the time needed to be 100% sure it's not there. Raise the issue right away. Tell your customer "Hey, there is no dragon in the box. I can't make up a dragon out of the other bricks. What do we do?"

相反，要做的是遵循该提示：“龙在哪里？”。花时间确保100％不存在。立即提出问题。告诉您的客户：“嘿，盒子里没有龙。我不能用其他砖头来补龙。我们该怎么办？”

People are surprisingly OK with problems when they know early enough. Discovering problems early opens more possible solutions. "Shall we continue knowing there is no dragon?" "Can we buy the dragon alone?" "I can see a dinosaur in the box. Can we use it instead?"

当人们足够早地知道问题时，他们会惊讶地接受问题。尽早发现问题可以提供更多可能的解决方案。 “我们继续知道没有龙吗？” “我们可以单独买龙吗？” “我可以在盒子里看到恐龙。我们可以代替它吗？”

4. 划清界限 (4. Draw a clear line)

When you start working on a new feature for an existing system, start by defining how it interfaces with the existing code. Of course you should try and follow SOLID principles etc. but the key part is simpler than that. Just try to make the touching surface as low as possible.

当您开始为现有系统开发新功能时，请先定义其与现有代码的接口。当然，您应该尝试遵循SOLID原则等。但是关键部分比这简单。只需尝试使接触表面尽可能低。

The simple process of clearly defining the cut will improve your solution. It will force you force you to tackle the key questions: How will the users or system use my code? What inputs will I get? What outputs should I produce? It helps you keep your eyes on the ball.

清晰定义切割的简单过程将改善您的解决方案。这将迫使您解决以下关键问题： 用户或系统将如何使用我的代码？ 我将得到什么输入？ 我应该产生什么输出？ 它可以帮助您将视线保持在球上。

This is even more true if you don't know much about the system you are working with yet. It is a good opportunity to explore the unknowns before diving into what you know already.

如果您对正在使用的系统不了解，那就更是如此。这是一个很好的机会，可以探索未知的事物，然后再深入了解您已经知道的事物。

It also makes it easy to turn the feature on or off. You can use a boolean flag or a more advance feature toggle mechanism.

这也使打开或关闭该功能变得容易。您可以使用布尔标志或更高级的功能切换机制。

LEGO analogy: Say you need to build an extension of the castle. Requirements are rather high level so there is plenty of room for creativity. You can't touch the existing castle though.

乐高类比 ：假设您需要建造城堡的延伸部分。要求很高，所以有很大的创造空间。但是您不能触摸现有的城堡。

You could go and build a great extension only to find out there is no space to attach it to the castle anywhere. That's unfortunate. You'll have to quickly alter your extension to make it fit somehow.

您可以去建造一个不错的扩展，只是发现没有空间将它连接到城堡的任何地方。那真不幸。您必须快速更改扩展名以使其适合。

The right approach would be to think of the touching surface first. Where will the extension be on the castle? What bricks can I attach it to? What form do they have? Put together the few bricks of the extension attaching it to the castle. Verify they plug for a solid connection. From there you can freestyle any extension you want.

正确的方法是首先考虑触摸表面。扩展名在城堡上哪儿？我可以把什么砖头贴在上面？他们有什么形式？将延伸部分的几块砖放在一起，将其连接到城堡。验证它们是否插入牢固。您可以从那里自由样式化任何所需的扩展。

5.不要太干 (5. Don't be too DRY)

DRY stands for Don't Repeat Yourself. That is probably the easiest rule to follow. As soon as you see duplicated lines of code, you make an abstraction. It can be a base class, a helper method, whatever.

DRY代表“不要重复自己”。这可能是最容易遵循的规则。一旦看到重复的代码行，就进行了抽象。可以是基类，也可以是辅助方法。

What happens then? The next person comes and the common code needs to change to cover more cases. They add parameters and if statements to cope with the emerging complexities. Soon, the 5 initial and simple lines become 30 lines and it's difficult to figure out what is happening.

那会发生什么呢？下一位来了，通用代码需要更改以涵盖更多情况。它们添加参数和if语句以应对新出现的复杂性。很快，最初的5条简单行变成了30条行，很难弄清正在发生什么。

Poor readability is not a good trade for code repetitions.

可读性差并不是代码重复的好方法。

It would have been better to keep the duplicated lines. You could then change each instance at will.

最好保留重复的行。然后，您可以随意更改每个实例。

The next time you reach for "abstraction over repetition", ask yourself: how many times did you see someone go back from an abstraction? Like removing a base class and putting the common code back to the inheriting classes. I bet the answer is never.

下次您到达“抽象的重复”时，问问自己：您看到某人从抽象中返回了多少次？就像删除基类，然后将通用代码放回继承类。我敢打赌答案永远不会。

The reason is abstractions and design patterns in general are cool and sophisticated. And if one exists then "there must be a good reason". So once you introduce the abstraction, there is a good chance it will stay there forever.

原因是抽象，设计模式通常很酷而且很复杂。如果存在，那么“一定有一个很好的理由”。因此，一旦您引入了抽象，就很有可能将其永久保留在那里。

Does this mean you should never use abstractions? No. User abstractions when they fit requirements. Things like:

这是否意味着您永远不应该使用抽象？否。满足需求的用户抽象。像：

"We want to log every call to this method with inputs outputs"
“我们希望使用输入输出记录对此方法的每次调用”
"We want to log every HTTP requests with data a, b, c"
“我们想用数据a，b，c记录每个HTTP请求”
"Every time a user is created we need to do this and that
“每次创建用户时，我们都需要这样做

These are good candidates for abstraction and there are many more examples. But notice how the requirements are more technical than business related (logging, security, analytics, etc.). It is rare that abstraction friendly requirements are part of your business domain.

这些是抽象的良好候选者，还有更多示例。但是请注意，与业务相关(日志记录，安全性，分析等)相比，这些需求的技术性更高。很少有抽象友好的需求成为您的业务领域的一部分。

Why? Because the business domain is close to the real world. And that we can't control. Assumptions made at the beginning of a project often fall short pretty soon. Don't over engineer code just to avoid repetition.

为什么？因为业务领域接近于现实世界。而且我们无法控制。在项目开始时所做的假设往往很快就会落空。不要为了避免重复而过度设计代码。

LEGO analogy: None. There is no DRY concept in Lego bricks.

乐高类比 ：无。乐高积木没有干的概念。