程序员和算法工程师一样吗?_像工程师一样做

程序员和算法工程师一样吗?

The work of a Software Engineer is to solve problems. Everything can be reduced to this activity. This is why it is important to have a solid methodology to tackle problems. We are engineers after all, and we are trained to solve problems. We have to do it like an engineer.

软件工程师的工作是解决问题。 一切都可以简化为该活动。 这就是为什么拥有可靠的方法来解决问题很重要的原因。 毕竟，我们是工程师，我们受过训练以解决问题。 我们必须像工程师一样去做。

了解要求 (Understand the requirements)

The first step is to understand the requirements. To solve a problem, you have to understand exactly what the problem is. It happened to me that a feature that would have been a 2/3 weeks work, became 3 useless months of “Oh, there is also that…”, “Oh, we didn’t think about that!”, and “Maybe it would be better if….”. My fault. Lesson learned. When you start solving a problem, be sure to understand the starting point, the end goal, and the obstacles in between. The worst possible thing is to produce a solution that actually doesn’t do what’s expected. As a final note, remember that you and only you decide how to solve the problem. It is your job, as it is the job of who gives you the requirements of the new feature to express them the best possible way. If someone that is not an engineer tries to tell you how to solve the problem, punch him in the face. You are perfectly justified. At least by me.

第一步是了解要求 。 要解决问题，您必须确切地了解问题所在。 我碰巧发现，一个原本需要2/3星期工作的功能变成了3个无用的“ 哦，还有…… ”，“ 哦，我们没想到！ ”和“ 如果……可能会更好。 ”。 我的错。 学过的知识。 当您开始解决问题时，请务必了解起点 ， 终点和两者之间的障碍 。 最糟糕的事情是产生一种实际上没有达到预期效果的解决方案。 最后一点，记住你 ，只有你决定如何解决问题。 这是您的工作，因为这是谁给您新功能的要求以最佳方式表达它们的工作。 如果不是工程师的人试图告诉您如何解决问题，请打他的脸。 你是完全有道理的。 至少是我

了解大小 (Understand the size)

we all agree that serving 100000 requests per second is a bit different from serving 100 requests per minute. The approach to solving the problem is different. This is why it is important to understand what is the “size of the input” or, put another way, how big the problem is. Otherwise, there are two scenarios. The best case is that you spend 6 months designing and implementing a system that is used at 10%. The worst case is when you spend 1 month designing a system that is used at 180%. If the best case is a waste of time/resources, you don’t want to find yourself in the worst case. To avoid this situation, we have to ask the right questions.

我们都同意每秒处理100000个请求与每分钟处理100个请求有些不同。 解决问题的方法是不同的。 这就是为什么重要的是要了解什么是“输入大小”，或者换句话说， 问题有多大 。 否则，有两种情况。 最好的情况是，您花了6个月的时间设计和实施一个使用率为10％的系统。 最坏的情况是，您花了1个月的时间设计了一个使用率达到180％的系统。 如果最好的情况是浪费时间/资源，那么您不想在最坏的情况下发现自己。 为了避免这种情况，我们必须提出正确的问题。

• How many requests the system should satisfy?

  系统应满足多少个请求？

• What is the expected response time?

  预期的响应时间是多少？

• How many resources do we have?

  我们有多少资源？

• What about deadlines?

  截止日期呢？

  The right questions depend on the context, but the target is one and only one:

  正确的问题取决于上下文，但目标是一个且只有一个：

  understand the size of the problem.

  了解问题的严重性 。

站在巨人的肩膀上…… (Stand on the shoulders of giants…)

I’ll tell you a secret. The chance someone else already solved your problem is high. Very high. All you have to do is a search in the literature to find out if there is a solution for a problem matching your use case. Avoid home-made solution to well-known problems, they only bring other problems. There are lots of companies having “their Hibernate”, “their Kafka”, etc. because:

我告诉你一个秘密。 别人已经解决您的问题的机会很高。 很高 。 您所要做的就是在文献中进行搜索，以找出是否存在解决与您的用例相匹配的问题的解决方案。 避免自制解决众所周知的问题，它们只会带来其他问题。 许多公司拥有“他们的Hibernate”，“他们的卡夫卡”等公司，原因是：

• “We have a different use case” (I want to see it)

  “我们有一个不同的用例” (我想看看)

• “The performance of technology X is not enough for us” (really?)

  “技术X的性能对我们来说还不够” (真的吗？)

• “We can do it better” (this is the funniest ?)

  “我们可以做得更好” (这是最有趣的吗？)

  Bottom line: once you know your requirements and the size of the problem, do a search in the literature.

  底线：一旦您知道您的要求和问题的严重性，请在文献中进行搜索。

  There is no point in reinventing the wheel.

  重新发明轮子毫无意义 。

…但是请记住你不是一个巨人 (…But remember you are not a giant)

It’s ok to build-up on existing solutions, but avoid overshooting. Remember that you are not Google. In the ocean of cool technologies out there, the most famous/innovative/used not always is the best one for you. Deploy a Kafka cluster to process 5 messages a day probably is not a good idea. Choose the technology that will do the job with the minimum complexity. This decision will pay you in the long run.

可以在现有解决方案上建立基础，但要避免过度调整。 请记住， 您不是Google 。 在酷技术的海洋中，最有名/创新/使用的并不总是最适合您的。 部署Kafka集群每天处理5条消息可能不是一个好主意。 选择将以最小的复杂度完成这项工作的技术。 从长远来看，这一决定将使您受益。

奶奶驱动的发展 (Grandma-Driven Development)

Implement your solution trying to make it understandable by your grandma. Avoid fancy and super complex implementations. Put them aside in favour of a simple and understandable one. This will make the code more maintainable. Leave optimization to the moment they are necessary. More formally, your implementation should follow the Rule of Least Power. The original rule refers to the choice of the programming language. In this context, we can read it as:

实施您的解决方案以使您的奶奶可以理解。 避免花哨和超复杂的实现。 将它们放在一边，而不是简单 易懂的 。 这将使代码更具可维护性。 将优化留在必要时。 更正式地说，您的实现应遵循“最低权力规则” 。 原始规则是指编程语言的选择。 在这种情况下，我们可以将其读取为：

“Among the available solutions, choose the least powerful one that can solve your problem.”

“在可用的解决方案中，选择功能最强大的解决方案，以解决您的问题。”

I learned this rule when I started using functional programming. It allows you to implement solutions with an unpaired elegance. However, such solutions sometimes are too much complex. I prefer an implementation a little less elegant and efficient, but a lot more understandable and maintainable. You will not be the only one reading your code.

当我开始使用函数式编程时，我学到了这个规则。 它使您可以无与伦比地实现解决方案。 但是，这种解决方案有时过于复杂。 我更喜欢一种实现方式，它的优雅度和效率要低一些，但要易于理解和维护。 您将不是唯一阅读代码的人 。

结论 (Conclusion)

We are engineers, our work is to solve problems, in whatever form they appear. We need to apply our engineering skills and analyze the problem pragmatically to deliver the correct solution. We need to remember that it is not the solution for producing the desired result. It is the one that does it requiring the least effort, and with the least complexity. I hope the methodology I described in this story will help you make a step toward such an achievement.

我们是工程师，我们的工作是以各种形式解决问题。 我们需要运用我们的工程技能并切实地分析问题，以提供正确的解决方案。 我们需要记住，这不是产生期望结果的解决方案。 它是需要最少的精力和最少的复杂性的工具 。 希望我在这个故事中描述的方法论可以帮助您迈出这一步。

See you! ?

再见！ ？

翻译自: https://www.freecodecamp.org/news/do-it-like-an-engineer/

程序员和算法工程师一样吗?