Utilisateur
次の文章をプログラマ視点で日本語でわかりやすく翻訳して
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