idea提高调试超时

by Nick Karnik

尼克·卡尼克(Nick Karnik)

如何提高您的调试技能 (How to Improve Your Debugging Skills)

All of us write code that breaks at some point. That is part of the development process. When you run into an error, you may feel that you don’t know what to do. However, even the most seasoned developers introduce errors and bugs that break their code. We are humans after all.

我们所有人编写的代码都会在某个时候中断。这是开发过程的一部分。当您遇到错误时，您可能会觉得自己不知道该怎么办。但是，即使是经验最丰富的开发人员，也会引入会破坏代码的错误和错误。毕竟我们是人类。

The important thing is to learn from these mistakes and avoid repeating them by developing techniques to improve your programming and debugging skills. Errors are primarily logical or syntactical. Some of them manifest via exceptions or crashes while others may only be observed when using the software.

重要的是要从这些错误中学习，并避免通过开发提高编程和调试技能的技术来重复这些错误。错误主要是逻辑上或语法上的。其中一些通过异常或崩溃来体现，而另一些则可能仅在使用该软件时被观察到。

这是开发人员犯的一些错误 (Here are some of the mistakes that developers make)

无法记录消息 (Failure to Log Messages)

One of the most unhelpful scenarios you can run into is when your program crashes and there are no error messages to indicate what went wrong. The first step is to identify if the program is crashing on start or during runtime. You can accomplish this by printing a simple log message to the terminal at the beginning of your code.

您可能会遇到的最无益的情况之一是程序崩溃时，没有错误消息指出发生了什么问题。第一步是确定程序是在启动时还是在运行时崩溃。您可以通过在代码开头将简单的日志消息打印到终端来完成此操作。

If you don’t see your log message, your program is most likely crashing while loading and it is possibly a dependency or build related issue.

如果您没有看到日志消息，则说明程序很可能在加载时崩溃，并且可能是依赖项或与构建有关的问题。

If you see your message, you need to narrow down to the general vicinity of the crash. The best way is to strategically place some log messages throughout your program depending upon how much information you have about the execution path by the time it crashes. Then, all you have to do is see which messages are printed.

如果看到您的消息，则需要缩小到崩溃的大致范围。最好的方法是根据程序崩溃时对执行路径的了解程度，从策略上在程序中放置一些日志消息。然后，您要做的就是查看打印了哪些消息。

无法读取错误消息 (Failing to Read Error Messages)

Exception messages on the front-end are usually displayed on the UI or developer console. Sometimes these messages are visible in the backend through the terminal or via log files. Regardless of where these errors occur, new developers are intimidated by them and fail to take the time to read them.

前端上的异常消息通常显示在UI或开发人员控制台上。有时，这些消息可以通过终端或日志文件在后端看到。不管这些错误发生在什么地方，新开发人员都会被它们吓倒，无法花时间阅读它们。

This is the number one reason why debugging takes longer for many developers. The first thing you should do is take the time to read the error message in front of you, let it sink in, and process it thoroughly.

这是许多开发人员调试时间更长的第一原因。您应该做的第一件事是花一些时间阅读面前的错误消息，让它沉入其中并进行彻底处理。

无法读取系统日志文件 (Failing to Read System Log Files)

Some programs generate log files or write to the system event log. There is often useful information in these logs. Even if it doesn’t tell you exactly what is wrong, there might be a warning or error message or even a success message providing a hint about what happened before the error occurred.

一些程序会生成日志文件或写入系统事件日志。这些日志中通常包含有用的信息。即使它不能告诉您确切的问题是什么，也可能会出现警告或错误消息，甚至可能还会显示一条成功消息，提示您在错误发生之前发生了什么。

无法写入跟踪日志 (Failing to Write Trace Logs)

Tracing is following your program flow and data. Writing trace messages throughout your program helps simplify the debugging process. Trace Logs are an easy way to keep track of program execution throughout the runtime of your application.

跟踪正在跟踪您的程序流和数据。在整个程序中编写跟踪消息有助于简化调试过程。跟踪日志是在整个应用程序运行时跟踪程序执行的简便方法。

无法进行增量更改，构建和测试它们 (Failing to Make Incremental Changes, Build Them, and Test Them)

Many developers write big chunks of code before building and testing it. The time to find bugs increases proportional to the amount of code that was changed. You should strive to make incremental changes, build them, and test them as frequently as possible. This will ensure that you don’t end up in a situation where a lot of code was written before you discover your program doesn’t work.

许多开发人员在构建和测试代码之前都会编写大量代码。发现错误的时间与更改的代码量成正比。您应该努力进行增量更改，构建它们，并尽可能频繁地对其进行测试。这将确保您不会在发现程序无法正常工作之前不会陷入编写大量代码的情况。

Often, I will even refactor my code to simplify what I’ve written.

通常，我什至会重构代码以简化编写的内容。

无法编写测试自动化 (Failing to Write Test Automation)

Unit-tests and end-to-end test automation allow you to catch potential errors as they happen. One of the reasons why existing code breaks is that developers refactor their code when they have low test coverage, which means all changes are not tested automatically.

单元测试和端到端自动化测试使您能够在潜在错误发生时及时发现它们。现有代码中断的原因之一是，开发人员在测试覆盖率较低时会重构代码，这意味着不会自动测试所有更改。

未能使用消除方法 (Failing to Use the Method of Elimination)

If you’re unable to identify the root cause of your issue, you need to use the method of elimination. You can comment out new blocks of code to see if the errors stop. Eliminating blocks of code will help you get closer to diagnosing the issue.

如果您无法确定问题的根本原因，则需要使用消除方法。您可以注释掉新的代码块以查看错误是否停止。消除代码块将帮助您进一步诊断问题。

You can form a certain hypothesis and try to prove or disprove it. Many times a simple assumption can prevent you from finding bugs.

您可以形成某种假设，然后尝试证明或反驳它。很多时候，简单的假设可能会阻止您发现错误。

从StackOverflow复制和粘贴 (Copying and Pasting from StackOverflow)

Often developers copy and paste code from stack overflow without understanding what it does. This has so many adverse effects. First, it is important that you pay attention to what goes into your application.

开发人员经常从堆栈溢出中复制和粘贴代码，而不了解其功能。这有很多不良影响。首先，重要的是要注意应用程序中包含的内容。

More often than I’d like, when I write a question on StackOverflow and think about how to effectively articulate it, I end up answering my own question!

当我在StackOverflow上写一个问题并考虑如何有效地表达它时，我比我想的要多得多，最终我回答了我自己的问题！

Similarly, sometimes when I talk to other members of the team, I end up answering my own question. This happens because it forces you to think about your solution.

同样，有时当我与团队中的其他成员交谈时，我最终会回答自己的问题。发生这种情况是因为它迫使您考虑解决方案。

未能再次解决他们的问题 (Failing to Solve their Problem Again)

One of the most successful debugging techniques I have found is to try to walk through your solution over and over again and in some cases try to re-implement certain functionality from scratch. This forces you to find potential issues by recreating your implementation.

我发现的最成功的调试技术之一就是尝试一遍又一遍地介绍您的解决方案，在某些情况下，尝试从头开始重新实现某些功能。这迫使您通过重新创建实现来发现潜在问题。

无法回溯 (Failing to Backtrack)

Normally, if you can isolate the symptoms to a specific area, you can start to walk up the call-stack to verify all variables and expected values. This can quickly lead you to uncover parts of your program where things are behaving unexpectedly.

通常，如果您可以将症状隔离到特定区域，则可以开始遍历调用堆栈以验证所有变量和期望值。这可以Swift导致您发现程序中异常运行的部分。

无法学习调试器 (Failing to Learn the Debugger)

Finally, the single best investment you can make in yourself is to learn to use a debugger. All IDE’s come with powerful debuggers. They follow the same basic concepts. They allow you to programmatically stop the execution of your application, either on start or in a specific part of the program flow.

最后，您可以自己进行的一项最佳投资就是学习使用调试器。所有的IDE都带有强大的调试器。它们遵循相同的基本概念。它们使您可以在启动时或在程序流的特定部分以编程方式停止执行应用程序。

There are also a ton of debugging tools that can aid in this process.

还有大量的调试工具可以帮助完成此过程。

If this article was helpful, ??? and Follow me on Twitter.

如果这篇文章有帮助，??? 然后在Twitter上关注我。

GitHub Extensions to Boost Your ProductivityHere are GitHub Extensions that I use. They will enable you to improve your productivity on GitHub. Please share your…medium.freecodecamp.org

可以提高生产力 的GitHub扩展这是我使用的GitHub扩展。 它们将使您能够提高GitHub上的生产率。 请分享您的… medium.freecodecamp.org