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