樂高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.

樂高類比 ：無。樂高積木沒有干的概念。