デバッグの6つのステップ

次の文章をプログラマ視点で日本語でわかりやすく翻訳して ``` welcome to this episode of Dev questions with Tim Corey join us as we tackle the questions you are asking about a career in software development understanding the industry and new technology if you are just starting out or you want to grow stronger as a developer this is the place to get your questions answered now here's your host expert developer and online educator Tim Corey what are the steps to quickly debugging an application this is a question is asked on a suggestion site and it's one I thought be a great question to answer in today's episode of Dev questions now every bug is a learning opportunity so let's start here don't waste it don't waste the opportunity to learn something from this bug so trying to escape early trying to just get somebody else to fix it for you these are ways to keep your growth stunted as a developer the way to grow as a developer is to learn how to debug by working through the tough stuff if you always try to escape the tough stuff you'll never be strong enough to stay on your own so you want to make sure that you work this list in order okay so don't just waste the debugging and stunt your growth instead I'm going to go over the six steps you should take to quickly debug an application if you do them in order you'll have a lot of success and you'll note that getting help doesn't come in till the end okay there's a lots of things that you can do regardless of your skill level there's lots of things you can do to learn how to debug earlier and more quickly okay so you're going to struggle through this this is going to be a struggle it almost always is a debugging debugging is just it's one of the things that developers have to do it's the thing that I struggle with because you're always going to have these weird bugs that you don't understand you don't know why they're working the way they are and it seems like you know you never get simple bugs it's G to happen and what's going to happen is you're going to figure out how to solve those and then that will become a simple bug after a few times and so you never have that again because you've learned how to avoid it in the first place you've become a better developer Okay so work these steps and don't skip steps okay the only time you ever skip a step is if you solve the problem okay if you get through step one you solve the problem cool no need to move on to the next step okay but otherwise go through this one by one this will also help you by the way when you get to the point of asking questions you will have the right information to give somebody to make them not upset at you to give them something that shows that you have put the work in yourself okay number one and here's where a lot of newer developers especially fall down they fail this step and try to go on a step two so don't miss this step number one clearly identify the issue don't just start trying to fix it identify what the problem is first okay that means that when your system pops up an error message don't just go Oh no I got an error message close it out and say now what you've you've missed part of the first step which is to read the error message the error messages today actually tell you in a lot of cases they tell you what the problem is maybe not the root problem but they tell you what their problem is things like uh we have a type mismatch or or we um have you know bad data invalid data or whatever the case may be they tell you some type of message that gives you a clue as to what is going on so clearly identify the issue read the error message write it down not not paraphrase get the actual message that way if you do end up Googling we'll get to that later but if you Google it well then you have the actual error message to put in there so you get an actual result not you know no results because that's not the actual error message it's just an approximation of the error message um reading log statements if you have logging going on and hopefully you do then read the logs see what happened watch what happened up to that point see what was going on identify the state of the application so for instance if you can if you know where the error is put a break point there and then run the application again and when it stops at that break point you hopefully know that the error is coming next before you get to that error look at what are the variables holding what information do they have what data is in memory what's it working with and working on to understand what was the state of the application when it broke and then identify which action tra here is the issue so is it certain input is it certain time Etc okay so try and figure out what's causing this what the actual issue is where the issue is you know anything else you can find about the system the state of it at the time now that's step number one and again you may find the issue at that point okay but if not then number two recreate the issue reliably so this is where you might say okay it looks like whenever I try to insert data into this table the application crashes so create a little test application that the only thing it does is inserts data into your your database wherever the the problem was and see if it crashes too and if it does you have a simple Recreation of your application not not all the bells and whistles not all the proprietary stuff not all of the the stuff that shouldn't matter just the actual thing that causes the problem try and recreate it reliably so set up a test environment verify the error occurs in that environment because if you know where the error is you know what's going on at the time of the error you should be able to recreate it in another environment in a clean project and if not well then you're missing some kind of context like is it that that machine is it some kind of configuration on that computer is there something I'm assuming that's not the case like for example maybe you're assuming you have a connection to the SQL server and it accidentally has connection to the MySQL server and that's different maybe that's it okay so try to recreate in a test environment and that's going to help you down the road when come to talking to people as well because now you have an example of the problem now once you haven't example the problem or if not once you're figure out how to recreate in the actual environment that crashes step through the code to observe the issue this is where you can use break points or Advanced breakpoints for example a breakpoint just pauses your code at a certain spot an advanced breakpoint might just count how many times the breakpoint gets hit so we can say hey I got this Loop how many times does it get hit I'm expecting 100 and then you put a break point after the loop and count the previous break point it says 10,000 and you're like Ah that's not right or it might say two and go Ah that's not right so now you use Advanced break points to give you more information use debugging log statements so you can put debugging statements in your code to say this method was hit this method was hit this method was hit and go on down a list or say hey here's a data at this spot here's a data at this spot and get more information about every step along the way where you may find hey wait we're missing a method call in here that method never got calls or this method got called but then it short circuited the process or whatever the case may be it helps you understand what's going on and then this is also helpful sometimes is to talk through what each line will do and what the inputs and outputs would be so out loud this may be where you bring the rubber duck in you talk through every line what you think the compiler is going to do this may be tedious maybe slow but what it helps you do is when you're talking out loud to something you know rubber duck that when you're talking out loud you kind of reveal some of your assumptions where you go and then the file gets loaded you're like wait wait wait what file where where did that file come from I don't have the file oh we're not loading the file there's the problem okay so by talking through you start talking through your assumptions okay number four break apart the system so if you have this long complicated process and it's breaking somewhere in there or it's it's breaking at one piece break apart and test each section independently so this is where unit test can be really helpful you validate multiple inputs and outputs for each little piece each little unit along the way and attempt to create the error in a specific method so maybe you've narrow it down to a section now break it down even further into a specific method so you can say okay when I pass in a two and a you know test is the word that breaks something let's find out why okay and so then you can create a unit test to test that and say yep that's when it breaks so and then replicate that problem in a new application okay again we're trying to pull this out into a test project re recreate the problem in a new application make it as simple as possible make the code generic and non proprietary this is where you find out oh some that proprietary code in that really tricky logic we created well that doesn't actually work and that's what's causing the problem because if you try to recreate with some generic code and you find out well that works then why doesn't ours work maybe you've been calling you know your your internal C you know company dll and it does some things for you like truncating strings and you know doing all uppercase in your string whatever it's doing right and you're calling that over and over again well take that out and put in your own code in that section and just see if it still has a problem because then you're eliminating some issues and you got something to recreate and this is where step six comes in talk it through with someone start again with that rubber duck so the overall the problem how you recreate it the whole thing talk it through with someone start the rubber duck because it's you know you can take as much time as you want with that rubber duck but what'll happen is you'll start talking through what's going on and it might trigger something then talk to a cooworker or a friend doesn't even have to be a developer just talk to someone and say hey this is what I'm doing just listen and maybe I might ask a stupid question that triggers something okay only after all those things do you then go talk to the internet and say hey internet I've got this problem because maybe there's a bug in the system maybe there's a bug inet that's causing the problem now most likely the answer is no the problem is in your code but by going through all those steps first you'll have all the information about how you recreate it what the error was what the log statements told you what the process was the the actual code you could give someone because it's generic and not proprietary and and it recreates the problem that you can show someone and they can test it and see the problem too because then they can say okay here's all little work you've done I can see that and it's still causing this problem okay I spot the problem and I I'm gonna feel you know fine about sharing you you know we all have blind spots we all don't no one knows everything and so sure you know I spot a problem I realize oh you didn't realize that in this case this happens okay not a problem you've now learned something new and you fixed the problem or they realize hey I can't get this solved either looks like it is a problem with the overall system we can escalate that up to let's say Microsoft support and they can look at it so by doing all those steps first you have really worked the problem you have tested things out you've gone as far as you can go and you have made sure that you have a full understanding of everything you can about what the problem is and how it operates knowing all of that will help you solve most of your problems but if you can't solve a problem knowing all of that will help you communicate clearly in a way that shows this is not a homework question this is not me just trying to avoid work this is I'm stuck I've done all the work I can and I just need someone to help me out and it's much more likely people will be willing to help you out if you do those steps I have seen people complain about things like stack Overflow I have never had a problem with stack Overflow I have asked multiple questions on stack Overflow I have asked questions to Microsoft employees before I've never had a problem I've never had people get angry at me or or downvote me and part of the reason why is because I don't come to them until I've gone through steps 1 through five thoroughly I don't go a step two until I understand fully the answers to step one I go through to step three until I understand fully the answers to step two and I go through step by step by step so that when I'm done when I ask a question it's thoroughly documented I have this long list of information here's a system I'm on here's the the versions of everything I'm using here is the recreation spot where I've recreated the problem here's the code I'm using here's the the error message I'm getting here's the problem here is like I summarize everything then I have all the details so that people know this is what my problem is and that tends to I won't say it always will because there's always angry people on the internet but it will help with that process I also talk to others first before I just go ask a random stranger on the internet I try and ask my co-workers and my friends first for help before I go out and ask just random people okay so this process will take you time you will struggle through this process and when you start working the process you might not understand the whole thing you might take a lot of time getting through steps one through five that's okay take the time don't shortcut the process like I said this is how you become a much better developer this is how you become a senior developer okay this is part of the process is understanding how to debug a system and it's not just go ask somebody else okay learn to do it on your own learn to build this skill up you will always have problems in your code because you don't write perfect code in need as anybody else so you're always going to have these problems you're always going have to work through them but the more you can work through yourself the more you build up this skill the faster you will be at debugging problems the less you will write actual bad code because you have seen it and you'll have learned how to fix it ahead of time and the better you will be at moving through an application and making those fixes okay so those are my six steps I encourage you to follow them take the time to work through them and make sure you really understand the problem and how to recreate it before you go and get help from someone else thanks for listening as always I am Tim Corey

ブレークポイントの使い方の具体的な内容の部分を翻訳して