前端工程师 后段工程师_如何像工程师一样思考

前端工程师 后段工程师

In my time in the tech field, I have learned that it really doesn’t matter what tools or languages you know. During your tenure in the field, you will pick up and discard multiple tools/languages. The things that will stay with you throughout your journey is:

在我从事技术领域的那段时间里，我了解到，您所知道的工具或语言真的无关紧要。 在现场任职期间，您将选择并丢弃多种工具/语言。 在整个旅程中，与您在一起的事情是：

• the lessons you learned along the way
  一路上你学到的教训
• your perspective
  你的观点
• your approach
  你的方法

These three things are some of the things that make experienced engineers so desirable. We have all heard the saying, “If all you have is a hammer, everything looks like a nail.” The same logic applies to being an engineer.

这三件事是使经验丰富的工程师如此渴望的一些事情。 我们都听到过这样的说法：“如果您只有锤子，一切都将像钉子。” 同样的逻辑适用于工程师。

You can pick up a new language or tool without issue, but knowing the right tool for the job is a lot harder.

您可以毫无问题地选择一种新的语言或工具，但是要知道适合该工作的正确工具要困难得多。

With that in mind, I wanted to share some of the important things I have learned in over 10 years that can help accelerate your growth as an engineer.

考虑到这一点，我想分享我在过去10年中学到的一些重要知识，这些知识可以帮助您加快工程师的成长。

建立模式 (Establish patterns)

What does “establish patterns” mean? It means don’t just fix today’s problem, fix tomorrow’s too. I briefly searched the internet and here is how Wikipedia describes it:

“建立模式”是什么意思？ 这意味着不仅要解决今天的问题，也要解决明天的问题。 我简短地搜索了互联网，下面是Wikipedia的描述方式：

In software engineering, a software design pattern is a general, reusable solution to a commonly occurring problem within a given context

在软件工程中 ， 软件设计模式是在给定上下文中对常见问题的通用可重用解决方案

Before we explain this further, lets give a real world example:

在我们进一步解释之前，让我们举一个真实的例子：

“I am having issues running code on my laptop/workstation because X isn’t installed or the right version.”

“由于未安装X或版本正确，因此在笔记本电脑/工作站上运行代码时遇到问题。”

I can imagine we have all have had this happen at some point or another. Maybe:

我可以想象我们都曾经在某个时候发生过这种情况。 也许：

• a coworker is using a different version of a library/binary
  同事正在使用其他版本的库/二进制文件
• a new dependency was added and you forgot to install it
  添加了新的依赖项，而您忘记安装它
• you are a new hire and trying to figure out how to get an application working.
  您是新员工，并且正在尝试弄清楚如何使应用程序正常工作。

The “common sense” solution would be to install or upgrade whatever is throwing an error right?

“常识”解决方案是安装或升级会引发错误的内容，对吗？

That approach would only fix the immediate problem. Perhaps, other dependencies are missing on your laptop. Even if the problem is fixed for today, there are no guarantees it won’t happen the next time someone updates the code base. Every time you hire a new engineer, they’ll have to go through the same pain as well.

这种方法只会解决眼前的问题。 也许，笔记本电脑上缺少其他依赖项。 即使问题已在今天解决，也无法保证下次有人更新代码库时不会发生。 每次雇用新工程师时，他们也将经历同样的痛苦。

Instead, what could you do that would fix the problem permanently? Something that wouldn’t only address the immediate problem but prevent it from happening to you or anyone else.

相反，您该怎么做才能永久解决问题？ 不仅解决紧急问题，而且可以防止您或其他任何人遇到这种问题。

You could build a runner or docker image that would automatically install all of your dependencies/tools/scripts etc… Every time you run the container, you will get a consistent experience. If your coworker adds a new dependency, it will get installed automatically. If you hire a new engineer, they can download the container and immediately start adding value. We have not even mentioned the fact that code can run differently based on your OS. With a container, everyone is using the same OS. If this container is an application, it also means that everyone is developing on the same image that will ultimately run in Production!

您可以构建一个运行器或docker映像，该映像将自动安装所有依赖项/工具/脚本等。每次运行容器时，您将获得一致的体验。 如果您的同事添加了新的依赖关系，它将自动安装。 如果您雇用了新工程师，他们可以下载容器并立即开始增加价值。 我们甚至没有提到基于您的操作系统代码可以不同地运行的事实。 使用容器，每个人都使用相同的操作系统。 如果此容器是一个应用程序，则也意味着每个人都在使用同一图像进行开发，最终将在生产环境中运行！

This example seems really easy and straight forward once you are presented with the answer, but many people today are still running npm install or brew install X on their local machines.

看到答案后，此示例似乎非常简单明了，但是今天许多人仍在其本地计算机上运行npm install或brew install X npm install 。

Establishing patterns is simultaneously the hardest and easiest thing to do, and it has the largest impact. Patterns are hard because it can be difficult to define an approach that you have never taken before. If you have never heard of docker or a runner, how would you know that you could use it to resolve this issue? This is where experience is a valuable thing. BUT, establishing patterns is also the easiest to do because you have the internet at your finger tips. I am a firm believer that if I am trying to solve a problem, someone else already hit that hurdle and overcame it. That being said, you still need to evaluate if the solutions you find are right for your situation. If the solutions are not the right for you, you can still draw inspiration from them or at least have an idea of what has been tried.

同时，建立模式是最困难和最容易的事情，并且影响最大。 模式之所以困难，是因为很难定义您从未使用过的方法。 如果您从未听说过docker或Runner，那么您怎么知道可以使用它来解决此问题？ 这是经验很有价值的地方。 但是，建立模式也是最容易做到的，因为您的指尖可以触及互联网。 我坚信，如果我要解决问题，那么已经有人克服了这个障碍。 话虽如此，您仍然需要评估找到的解决方案是否适合您的情况。 如果解决方案不适合您，您仍然可以从中获得启发，或者至少对尝试过的方法有所了解。

This is where I also highly recommend always reading articles, talking with fellow engineers, or attending conferences. You might figure out how to improve something you didn’t even know could be improved.

在此，我也强烈建议您始终阅读文章，与其他工程师交谈或参加会议。 您可能会想出如何改进甚至不知道可以改进的东西。

It is worth mentioning that building the runner would take a few hours compared to the 5 minute fix, but:

值得一提的是，与5分钟的修复相比，构建跑步者需要花费几个小时，但是：

• Think of all the time you saved by never having this problem again
  想一想您节省下来的所有时间，不再遇到这个问题
• Think of all the time you saved your coworkers
  想一想您保存同事的所有时间
• Think how easy it just became to add new tools for you and the entire team to use
  考虑一下为您和整个团队添加新工具变得多么容易
• Consider that the container can also be used as part of your CI/CD pipeline to run test or do anything you want.
  考虑到该容器还可以用作CI / CD管道的一部分，以运行测试或执行任何您想做的事情。
• Last, remember that context switching is expensive. It is a 5 minute fix every time, and then another 30 minutes to get back to the right mindset before you were interrupted.
  最后，请记住上下文切换非常昂贵。 每次都需要5分钟的修复，然后又需要30分钟才能恢复到正确的心态，然后才被打扰。

I once knew a brilliant engineer that consistently produced more than double the code compared to his peers. The code worked well, was high quality, and years laters, I know it is still in use somewhere. He told me that he spent only 20% of his time coding. The other 80% of his time was spent thinking/processing what he wanted to do and why. Let that sink it.

我曾经认识一位出色的工程师，与他的同行相比，他始终如一地产生两倍以上的代码。 该代码运行良好，质量很高，几年后，我知道它仍在某处使用。 他告诉我说他只花20％的时间在编码上。 他80％的时间都花在思考/处理他想做什么以及为什么做。 让它沉没。

不要害怕为正确的工作使用正确的工具。 (Don’t be afraid to use the right tool for the right job.)

This directly goes back to the Hammer/Nail analogy that we mentioned at the beginning of this article. It doesn’t matter how skillful you are with a hammer, it will never be a wrench.

这可以直接回到本文开头提到的锤子/钉子类比。 锤子的熟练程度无所谓，永远不会成为扳手。

If I provided an example here, it might be too specific to provide value. To give you an idea though, in our automation we make use of:

如果我在此处提供示例，则可能太具体而无法提供价值。 为了给您一个想法，我们在自动化中使用：

• helm
  舵
• helmsman
  舵手
• drone
  无人驾驶飞机
• terraform
  地貌
• python scripts
  python脚本
• Golang
  高朗
• custom docker images
  自定义docker映像
• etc…
  等等…

Different tools shine at different things, and it’s okay to use them. Now I do want to clarify what we are and are NOT doing.

不同的工具会在不同的地方发挥作用，可以使用它们。 现在，我想澄清一下我们在做什么和没有做什么。

我们是： (We are:)

• Using the best tool for a given task
  使用最佳工具完成特定任务
• Consistently using the same tool for the same job
  始终使用相同的工具完成相同的工作
• Using complimentary tools (that enable things to be fully automated)
  使用免费工具(使事情完全自动化)
• Using tools with declarative languages where the config can be defined in code (which is versioned, and peer reviewed)
  使用声明性语言的工具，可以在代码中定义配置(版本化，并经过同行评审)
• Using tool/scripts that are idempotent
  使用幂等的工具/脚本

我们不是： (We are not:)

This entire section is just to highlight “Consistently using the same tool for the same job”. It is okay to complimentary tools, but not competing tools (e.g. cloud formation vs terraform).

整个部分仅强调“始终为同一工作使用相同的工具 ”。 可以使用免费工具，但不能使用竞争工具(例如，云形成与地形)。

Once we decide a tool is going to be used for X, that is the only tool we use for X.

一旦确定要用于X的工具，那便是我们用于X的唯一工具。

If we decide to use Terraform for deploying our infrastructure, it will be the only tool that we use for the infrastructure, no cloud formation, no manual deploys, no anything!!! Once we decide to deploy Kubernetes packages using helm, you won’t find us deploying anything with raw YAML.

如果我们决定使用Terraform来部署我们的基础架构，它将是我们用于基础架构的唯一工具，没有云形成，没有手动部署，什么都没有！！！ 一旦决定使用Helm部署Kubernetes软件包，您将不会发现我们使用原始YAML部署任何东西。

Remember the first thing we discussed, “Establish patterns”. If you solve a recurring problem using different methods each time, that introduces needless friction to the automation, and is generally confusing. It also causes duplication of work and means that whenever you do anything, you have to account for multiple approaches instead of one.

记住我们讨论的第一件事，“建立模式”。 如果您每次都使用不同的方法解决重复出现的问题，则会给自动化带来不必要的摩擦，并且通常会造成混乱。 它还会导致工作重复，这意味着无论何时执行任何操作，都必须考虑多种方法而不是一种方法。

附录： (Addendum:)

Custom tools and scripts - It is 100% fine to build your own tools in-house. Before making that decision though, you should check if someone or some company already did it first. Custom tooling and scripts are always spoken of in very romantic terms. “Oh, I can make it do whatever I want, however I want, whenever I want”. While that statement is very true, building anything from scratch is also very involved and introduces overhead that you don’t have when using a tool maintained by a community or company. This problem only get multiplied for every custom tool you create/maintain.

自定义工具和脚本-在内部构建自己的工具是100％好的。 不过，在做出决定之前，您应该先检查是否有人或某家公司已经做出决定。 自定义工具和脚本总是用非常浪漫的术语来谈论。 “哦，无论何时我想，我都可以让它做我想做的任何事情”。 尽管该说法是正确的，但从头开始构建任何东西也很复杂，并且会引入使用社区或公司维护的工具时没有的开销。 对于创建/维护的每个自定义工具，此问题只会成倍增加。

Again, custom tools are fine, just make sure it is the right tool for the right job (and worth the cost/overhead).

同样，自定义工具也不错，只需确保它是适合正确工作的正确工具(并值得付出成本/开销)。

自动化一切 (Automate Everything)

I have heard Amazon engineers use a term that has really stuck with me throughout the years, “undifferentiated heavy lifting”. In order to keep growing, Amazon can’t just keep adding more employees. Instead they keep identifying tasks that are necessary, repetitive, but don’t change between iterations, and find a way to automate it. You can do the same thing, easily.

我听说亚马逊工程师使用了多年来一直困扰我的术语，“毫无差别的繁重工作”。 为了保持增长，亚马逊不能仅仅继续增加雇员。 相反，他们不断地确定必要的，重复的但在迭代之间不改变的任务，并找到一种使之自动化的方法。 您可以轻松地执行相同的操作。

A real world example is: “Every time I stand up an AWS account, I have to look up the AMI IDs that I need to provision my infrastructure.”

一个真实的例子是：“每次我建立一个AWS账户时，我都必须查找配置基础结构所需的AMI ID。”

This tasks is fairly easy and straight forward, but it is a manual step:

这些任务非常简单直接，但这是一个手动步骤：

• Someone has to remember this step is needed
  有人必须记住此步骤是必需的
• Someone actually has to do it
  实际上有人必须这样做
• It does not provide value except that it “unblocks” the automation
  它没有提供价值，除非它“解除阻碍”了自动化

An engineer I was working came across this problem and said “I don’t want to do this anymore”. They created a data resource in Terraform that would automatically look up the AMIs. Forevermore, we do not have to look up the AMIs and instead we were able to focus on the bigger problems.

我正在工作的一位工程师遇到了这个问题，并说：“我不想再这样做了”。 他们在Terraform中创建了一个数据资源，该资源将自动查找AMI。 永远，我们不必查找AMI，而能够专注于更大的问题。

持续增长 (Keep Growing)

If you have been in the tech field any amount of time, you will know that it is constantly changing. Limits are constantly broken. Languages come and go or get reinvented. A few years ago, Kubernetes & Docker were not really a thing, but now they are everywhere. With their adoption also came a slew of tools and applications. Like the tech, you also have to keep evolving. This means a few things:

如果您曾经在技术领域工作过一段时间，您就会知道它在不断变化。 极限不断被打破。 语言来来去去或被重新发明。 几年前，Kubernetes和Docker并不是真正的东西，但是现在它们无处不在。 随着它们的采用，出现了许多工具和应用程序。 像高科技一样，您还必须不断发展。 这意味着几件事：

• Never stop reading articles, attending conferences, or learning
  永远不要停止阅读文章，参加会议或学习
• Don’t go into an argument thinking: “I am the senior engineer”, or “I am right”. Actually listen to the argument, and if your approach wasn’t the best, learn from it. Even if you are “right” in the end, it will still be an opportunity to help someone else grow.
  不要争论：“我是高级工程师”或“我是对的”。 实际听取争论，如果您的方法不是最好的方法，请向它学习。 即使最终您“正确”，它仍将是一个帮助他人成长的机会。
• Periodically look at old projects and see where you could have done things better.
  定期查看旧项目，看看可以做得更好的地方。
• Setup POCs of new tools and languages and take them for a test drive. Even if it turns out your current languages/tools are better, you will still be able to articulate why they are better instead of saying “It is what we have always used”.
  设置新工具和语言的POC，并进行测试。 即使事实证明您当前的语言/工具更好，您仍然可以阐明为什么它们更好，而不必说“这是我们一直使用的语言”。
• Don’t be afraid to change because “We have always done it this way”. Still consider ROI, but if the change makes sense, do it.
  不要害怕改变，因为“我们一直都这样做”。 仍要考虑投资回报率，但是如果更改有意义，那就去做吧。

This particular topic is something that is very well understood and I am sure many articles have been written on this alone so I won’t belabor it. Just keep growing!

这个主题很容易理解，我敢肯定，仅此主题就写过很多文章，因此我不会感到惊讶。 保持增长！

结论 (Conclusion)

By now you have probably noticed that all of these sections tie into each other in one way or another. There is a reason for this. What I am hoping to communicate is that one of the keys to becoming a senior engineer is your mentality. Establishing patterns, using the right tools, and automation go hand in hand. Without knowledge, you also cannot do any of these things either.

到目前为止，您可能已经注意到，所有这些部分都以一种或另一种方式相互关联。 有一个原因。 我希望传达的是，成为高级工程师的关键之一就是您的心态。 建立模式，使用正确的工具和自动化是齐头并进的。 没有知识，您也不会做任何这些事情。

Every single day, you will have a million distractions or small issues attempting to take your focus away from the bigger problems you are trying to solve. Sometimes the distractions feel like death by a thousand paper cuts. These “paper cuts” affect your productivity; they also affect the productivity of the entire team.

每一天，您都会有上百万个分心或小问题，试图将精力从解决的大问题上转移开。 有时候，一千个剪纸的干扰使人分心。 这些“剪纸”会影响您的生产力。 它们也会影响整个团队的生产力。

Next time you run into a problem, keeps these points in mind. They will help you make better decisions and with enough repetition, help you grow as well.

下次遇到问题时，请记住这些要点。 它们将帮助您做出更好的决策，并通过重复多次来帮助您成长。

翻译自: https://medium.com/dev-genius/how-to-think-like-an-engineer-3b53fb42ac13

前端工程师 后段工程师