idea提高調(diào)試超時(shí)

by Nick Karnik

尼克·卡尼克(Nick Karnik)

如何提高您的調(diào)試技能 (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.

我們所有人編寫(xiě)的代碼都會(huì)在某個(gè)時(shí)候中斷。 這是開(kāi)發(fā)過(guò)程的一部分。 當(dāng)您遇到錯(cuò)誤時(shí)，您可能會(huì)覺(jué)得自己不知道該怎么辦。 但是，即使是經(jīng)驗(yàn)最豐富的開(kāi)發(fā)人員，也會(huì)引入會(huì)破壞代碼的錯(cuò)誤和錯(cuò)誤。 畢竟我們是人類。

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.

重要的是要從這些錯(cuò)誤中學(xué)習(xí)，并避免通過(guò)開(kāi)發(fā)提高編程和調(diào)試技能的技術(shù)來(lái)重復(fù)這些錯(cuò)誤。 錯(cuò)誤主要是邏輯上或語(yǔ)法上的。 其中一些通過(guò)異常或崩潰來(lái)體現(xiàn)，而另一些則可能僅在使用該軟件時(shí)被觀察到。

這是開(kāi)發(fā)人員犯的一些錯(cuò)誤 (Here are some of the mistakes that developers make)

無(wú)法記錄消息 (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.

您可能會(huì)遇到的最無(wú)益的情況之一是程序崩潰時(shí)，沒(méi)有錯(cuò)誤消息指出發(fā)生了什么問(wèn)題。 第一步是確定程序是在啟動(dòng)時(shí)還是在運(yùn)行時(shí)崩潰。 您可以通過(guò)在代碼開(kāi)頭將簡(jiǎn)單的日志消息打印到終端來(lái)完成此操作。

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.

如果您沒(méi)有看到日志消息，則說(shuō)明程序很可能在加載時(shí)崩潰，并且可能是依賴項(xiàng)或與構(gòu)建有關(guān)的問(wèn)題。

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.

如果看到您的消息，則需要縮小到崩潰的大致范圍。 最好的方法是根據(jù)程序崩潰時(shí)對(duì)執(zhí)行路徑的了解程度，從策略上在程序中放置一些日志消息。 然后，您要做的就是查看打印了哪些消息。

無(wú)法讀取錯(cuò)誤消息 (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或開(kāi)發(fā)人員控制臺(tái)上。 有時(shí)，這些消息可以通過(guò)終端或日志文件在后端看到。 不管這些錯(cuò)誤發(fā)生在什么地方，新開(kāi)發(fā)人員都會(huì)被它們嚇倒，無(wú)法花時(shí)間閱讀它們。

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.

這是許多開(kāi)發(fā)人員調(diào)試時(shí)間更長(zhǎng)的第一原因。 您應(yīng)該做的第一件事是花一些時(shí)間閱讀面前的錯(cuò)誤消息，讓它沉入其中并進(jìn)行徹底處理。

無(wú)法讀取系統(tǒng)日志文件 (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.

一些程序會(huì)生成日志文件或?qū)懭胂到y(tǒng)事件日志。 這些日志中通常包含有用的信息。 即使它不能告訴您確切的問(wèn)題是什么，也可能會(huì)出現(xiàn)警告或錯(cuò)誤消息，甚至可能還會(huì)顯示一條成功消息，提示您在錯(cuò)誤發(fā)生之前發(fā)生了什么。

無(wú)法寫(xiě)入跟蹤日志 (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.

跟蹤正在跟蹤您的程序流和數(shù)據(jù)。 在整個(gè)程序中編寫(xiě)跟蹤消息有助于簡(jiǎn)化調(diào)試過(guò)程。 跟蹤日志是在整個(gè)應(yīng)用程序運(yùn)行時(shí)跟蹤程序執(zhí)行的簡(jiǎn)便方法。

無(wú)法進(jìn)行增量更改，構(gòu)建和測(cè)試它們 (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.

許多開(kāi)發(fā)人員在構(gòu)建和測(cè)試代碼之前都會(huì)編寫(xiě)大量代碼。 發(fā)現(xiàn)錯(cuò)誤的時(shí)間與更改的代碼量成正比。 您應(yīng)該努力進(jìn)行增量更改，構(gòu)建它們，并盡可能頻繁地對(duì)其進(jìn)行測(cè)試。 這將確保您不會(huì)在發(fā)現(xiàn)程序無(wú)法正常工作之前不會(huì)陷入編寫(xiě)大量代碼的情況。

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

通常，我什至?xí)貥?gòu)代碼以簡(jiǎn)化編寫(xiě)的內(nèi)容。

無(wú)法編寫(xiě)測(cè)試自動(dòng)化 (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.

單元測(cè)試和端到端自動(dòng)化測(cè)試使您能夠在潛在錯(cuò)誤發(fā)生時(shí)及時(shí)發(fā)現(xiàn)它們。 現(xiàn)有代碼中斷的原因之一是，開(kāi)發(fā)人員在測(cè)試覆蓋率較低時(shí)會(huì)重構(gòu)代碼，這意味著不會(huì)自動(dòng)測(cè)試所有更改。

未能使用消除方法 (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.

如果您無(wú)法確定問(wèn)題的根本原因，則需要使用消除方法。 您可以注釋掉新的代碼塊以查看錯(cuò)誤是否停止。 消除代碼塊將幫助您進(jìn)一步診斷問(wèn)題。

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

您可以形成某種假設(shè)，然后嘗試證明或反駁它。 很多時(shí)候，簡(jiǎn)單的假設(shè)可能會(huì)阻止您發(fā)現(xiàn)錯(cuò)誤。

從StackOverflow復(fù)制和粘貼 (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.

開(kāi)發(fā)人員經(jīng)常從堆棧溢出中復(fù)制和粘貼代碼，而不了解其功能。 這有很多不良影響。 首先，重要的是要注意應(yīng)用程序中包含的內(nèi)容。

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!

當(dāng)我在StackOverflow上寫(xiě)一個(gè)問(wèn)題并考慮如何有效地表達(dá)它時(shí)，我比我想的要多得多，最終我回答了我自己的問(wèn)題！

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.

同樣，有時(shí)當(dāng)我與團(tuán)隊(duì)中的其他成員交談時(shí)，我最終會(huì)回答自己的問(wèn)題。 發(fā)生這種情況是因?yàn)樗仁鼓紤]解決方案。

未能再次解決他們的問(wèn)題 (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.

我發(fā)現(xiàn)的最成功的調(diào)試技術(shù)之一就是嘗試一遍又一遍地介紹您的解決方案，在某些情況下，嘗試從頭開(kāi)始重新實(shí)現(xiàn)某些功能。 這迫使您通過(guò)重新創(chuàng)建實(shí)現(xiàn)來(lái)發(fā)現(xiàn)潛在問(wèn)題。

無(wú)法回溯 (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.

通常，如果您可以將癥狀隔離到特定區(qū)域，則可以開(kāi)始遍歷調(diào)用堆棧以驗(yàn)證所有變量和期望值。 這可以Swift導(dǎo)致您發(fā)現(xiàn)程序中異常運(yùn)行的部分。

無(wú)法學(xué)習(xí)調(diào)試器 (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.

最后，您可以自己進(jìn)行的一項(xiàng)最佳投資就是學(xué)習(xí)使用調(diào)試器。 所有的IDE都帶有強(qiáng)大的調(diào)試器。 它們遵循相同的基本概念。 它們使您可以在啟動(dòng)時(shí)或在程序流的特定部分以編程方式停止執(zhí)行應(yīng)用程序。

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

還有大量的調(diào)試工具可以幫助完成此過(guò)程。

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

如果這篇文章有幫助，??? 然后在Twitter上關(guān)注我。

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

可以提高生產(chǎn)力 的GitHub擴(kuò)展這是我使用的GitHub擴(kuò)展。 它們將使您能夠提高GitHub上的生產(chǎn)率。 請(qǐng)分享您的… medium.freecodecamp.org

翻譯自: https://www.freecodecamp.org/news/how-to-improve-your-debugging-skills-abb5b363bdb8/

idea提高調(diào)試超時(shí)

總結(jié)

以上是生活随笔為你收集整理的idea提高调试超时_如何提高您的调试技能的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。