Debugging is one of those tedious, but necessary aspects of any software engineering team’s work.

调试是任何软件工程团队工作中那些乏味但必不可少的方面之一。

Before sending a product to market, you want to make sure it’s error-free.

在将产品投放市场之前，您要确保它没有错误。

Granted, there’s a balance to strike between writing clean code and delivery. Perfect can quickly become the enemy of shipped (for more on that, check out this article about avoiding unnecessary performance optimization).

当然，在编写干净的代码和交付之间要取得平衡。 完美可以很快成为已交付产品的敌人(有关更多信息，请查看本文，以避免不必要的性能优化 )。

But to create a quality product, debugging will have to be part of the process.

但是要创建高质量的产品，调试将成为过程的一部分。

We sat down with Mitch Pirtle, VP of Engineering at Morning Consult, to delve into the significance of debugging. We also talked about work efficiency when tackling and solving an unknown problem.

我们与Morning Consult工程部副总裁Mitch Pirtle坐了下来，探讨了调试的重要性。 我们还谈到了解决和解决未知问题时的工作效率。

He explained the fundamental steps of the debugging process and the common challenges involved. He also provided an insider’s perspective on the overall impact debugging has on operations and how it contributes to fostering the culture at Morning Consult.

他解释了调试过程的基本步骤以及所涉及的常见挑战。 他还提供了内部人的观点，以了解调试对运营的总体影响以及它如何在Morning Consult中促进文化的培养。

The conversation below has been edited for length and content. How do you approach debugging errors in a program?

下面的对话已进行了长度和内容的编辑。 您如何处理程序中的调试错误？

The first thing I look at is the instrumentation.

我首先要看的是仪器。

Where are my logs?

我的日志在哪里？

Depending on what we’re building, there has to be something I can look at to see what happened and what might have caused the problem.

根据我们要构建的内容，我必须查看一些内容以了解发生了什么以及可能引起问题的原因。

Based on this, the second question I ask myself is do we need to fix this?

基于此，我问自己的第二个问题是我们是否需要解决此问题？

For example, we fully automated our infrastructure on the cloud to the point where we’re using Spot Instances now because it’s more cost-effective for us.

例如，我们将云上的基础架构完全自动化到了现在使用竞价型实例的地步，因为它对我们而言更具成本效益。

I’d rather launch a bunch of cheap instances than a couple of expensive instances that never go down. That means you’ll have something get a little frisky and fail on you, but you won’t know if it’s your code or a problem with the hardware. The question then is — was this a transient failure or a repeating issue that actually needs to be resolved?

我宁愿启动一堆廉价实例，而不是几个永远不会失败的昂贵实例。 这意味着您会有些生气，并且失败了，但是您不知道这是您的代码还是硬件问题。 那么问题是–这是暂时性的故障还是实际上需要解决的重复性问题？

After looking at the evidence that it happened in the first place and justifying that there’s an issue to be looked at, I would say walk down the stack to see where the initial cause of that problem came from.

首先查看了发生这种情况的证据并证明有待解决的问题是合理的，然后我说说走下去，看看导致该问题的最初原因是什么。

At Morning Consult, we’re in the process of kicking off an effort to automate distributed testing of our systems. For example, when one of our backend teams wants to deploy a new update to an API service that the front-end teams are relying on (one that builds and runs on staging), we want an automated system to grab all of the other staging environments and test on that API service to make sure that from an external testing perspective everything is still kosher and good.

在Morning Consult，我们正在努力使系统的分布式测试自动化。 例如，当我们的一个后端团队希望将新的更新部署到前端团队所依赖的API服务(一个在临时环境上构建和运行)时，我们希望一个自动化系统来捕获所有其他临时环境环境，并对该API服务进行测试，以确保从外部测试的角度来看，一切仍然是正确的和良好的。

We really rely on that testing and coverage. When something does go wrong, we can at least be informed of it and say this is something we need to look at. Typically, you also know where to look based on the error you’re getting.

我们确实依靠测试和覆盖。 当确实出现问题时，我们至少可以得到通知，并说这是我们需要研究的问题。 通常，您还会根据收到的错误知道在哪里查找。

What are some of the challenges you face while debugging?

您在调试时面临哪些挑战？

Generally, the engineers are writing code. The code gets reviewed by two engineers. When the engineers say it’s good to go, it gets merged. Our CI pipeline picks it up and runs tests. Passing all the tests isn’t good enough. It has to check how much is being covered because you could be testing only 10% of the conditions. When everything is thumbs up, it goes live.

通常，工程师正在编写代码。 该代码经过两名工程师的审查。 当工程师们说很好时，它就被合并了。 我们的CI管道将其拾取并运行测试。 通过所有测试还不够。 它必须检查承保范围是多少，因为您只能测试10％的条件。 当一切都竖起大拇指时，它就会生效。

We’re going to be leveraging Kubernetes so that developers are no longer running the applications locally on their machines when they’re developing, but the experience remains the same.

我们将利用Kubernetes，以便开发人员在开发时不再在其计算机上本地运行应用程序，但体验仍然是一样的。

If I’m editing a text file, save, go to my browser, and reload, I see the changes but none of that is actually running on my computer. It’s running on my own private namespace. As a manager, nothing makes me want to bang my head on the pavement faster than when developers say “but it runs on my laptop.”

如果我正在编辑文本文件，保存，进入浏览器并重新加载，我会看到所做的更改，但实际上这些更改均未在计算机上运行。 它在我自己的私有名称空间上运行。 作为一名经理，没有什么比让开发人员说“但它可以在我的笔记本电脑上运行”更快地敲打人行道了。

So that’s another challenge: avoiding dependents on local configuration.

因此，这是另一个挑战：避免依赖本地配置。

Once a system is deployed in any state, whether it be staging or production, we would rather have way too many logs than not enough. Then we build alerting based on the intelligence of those logs. That takes a lot of work and gumption to sit through. There’s a lot of white noise when you first set this up because it’s so noisy. After a while you just want to turn it off. That’s where most companies fall short.

一旦将系统部署到任何状态(无论是暂存状态还是生产状态)，我们宁可拥有太多日志，还是不足以容纳更多日志。 然后，我们基于这些日志的智能来构建警报。 这需要大量的工作和努力。 初次设置时会有很多白噪声，因为它太吵了。 一段时间后，您只想将其关闭。 那就是大多数公司都无法做到的地方。

If something breaks, we’re all just curious to know what happened, even if it’s totally useless knowledge in the end. Being rooted that way, we just stick with it until we get to the point where we only see alerts that are really relevant.

如果有什么事情发生了，我们所有人都很好奇知道发生了什么，即使最终这完全是无用的知识。 以这种方式扎根，我们一直坚持下去，直到我们只看到真正相关的警报为止。

How has this debugging mindset fostered the culture at Morning Consult?

这种调试思维方式​​如何促进了Morning Consult的文化？

I think it’s due to practicality more than anything else.

我认为这归功于实用性。

Alex, our CTO, was pretty much a one-man army for the first several years of our existence as a business. He had to learn a lot of things the hardest way possible. He automated himself out of a job as fast as he could.

我们的首席技术官亚历克斯(Alex)在我们开展业务的头几年中几乎是一支单人军队。 他必须以最困难的方式学习很多东西。 他以最快的速度使自己失业。

When I got here two years ago, I was thinking — I’ve got to dig deep to contribute here because they’ve already automated all the things. That was very rare, even in modern times, to walk into a startup this young and small. Usually there are really good engineers, but they can’t make anything go. This was the opposite. We didn’t really have many engineers, but we had everything fully automated on Amazon.

两年前，当我来到这里的时候，我在想-我必须在这里做深一点的贡献，因为他们已经使所有事情自动化了。 即使在现代，也很少有人走进这样一个年轻而又小的公司。 通常情况下，确实有很好的工程师，但是他们什么也做不了。 相反。 我们实际上没有多少工程师，但是我们在亚马逊上拥有了完全自动化的一切。

I would say that in a nutshell, engineering at Morning Consult means the KISS principle. It’s brutal minimalism as software engineering.

简而言之，Morning Consult的工程意味着KISS原则。 作为软件工程，这是残酷的极简主义。

Only code what you have to code. Nothing more.

只编码您必须编码的内容。 而已。

You don’t introduce bugs. You’re not predicting the future. You’re just doing what you need to do and then moving on.

您不会引入错误。 您不是在预测未来。 您只是在做您需要做的，然后继续前进。

It keeps things simple and that means extending them is simple, debugging is simple, and scaling things out is simple.

它使事情保持简单，这意味着扩展它们很简单，调试也很简单，向外扩展很简单。

How does Morning Consult encourage efficiency differently than other startups?

与其他初创公司相比，Morning Consult如何提高效率？

In my eyes, part of what makes recruiting for Morning Consult so fun as a VP of Engineering is I know that the environment here gives you that opportunity for learning. It’s a very learning-rich, growth-rich environment without the craziness and toxicity that you see in a lot of startups.

在我眼中，让Morning顾问作为工程副总裁如此有趣的部分原因是，我知道这里的环境为您提供了学习的机会。 这是一个非常学习丰富，增长充沛的环境，没有许多初创企业所见的疯狂和毒性。

Engineering-wise, and across the organization, we always gravitate toward team-first, low ego mentality. I joke that we’re all plant eaters. If I was to introduce a meat eater, it would be devastating.

从工程角度出发，在整个组织中，我们始终倾向于团队第一，低自我的心态。 我开玩笑说我们都是植物人。 如果我要介绍吃肉者，那将是毁灭性的。

If there’s a conflict, you’re not going to see engineers just taking potshots at each other or reverting each other’s commits and doing the whole passive aggressive arguing stuff.

如果存在冲突，您将不会看到工程师只是互相争吵或恢复对方的提交，而做整个被动的，激进的争论。

They talk about it.

他们谈论它。

“Well, why do you think this is the best idea? I always thought it was that.”

“好吧，为什么您认为这是最好的主意？ 我一直以为是那样。”

It’s an honest conversation between two people and the goal of those conversations is always to get better. It’s never to shame or be better than someone else.

这是两个人之间的诚实对话，这些对话的目标始终是变得更好。 永远不要羞于别人或比别人更好。

We strive to get better as a team.

我们努力成为一个更好的团队。

Originally published at https://dmv.myhatchpad.com.

最初发布在 https://dmv.myhatchpad.com 。