Return to Video

What You Can Do - Software Debugging

  • 0:00 - 0:06
    At the end of the day, we'd all prefer creating over debugging.
  • 0:06 - 0:08
    So how can we avoid debugging in the first place?
  • 0:08 - 0:11
    Here's some suggestions on what you can do.
  • 0:11 - 0:15
    First thing, get your requirements right.
  • 0:15 - 0:23
    Only if you know precisely what to do will you be able to know what not to do.
  • 0:23 - 0:31
    That is, only with precise requirements will you be able to tell failure from success.
  • 0:31 - 0:35
    A famous quote coming from Brian Kernighan:
  • 0:35 - 0:40
    "Without specification, there are no bugs--only surprises."
  • 0:40 - 0:44
    So you could think that if you have no specifications,
  • 0:44 - 0:47
    then you wouldn't have to do any debugging.
  • 0:47 - 0:52
    Unfortunately, surprises need to be debugged just as well,
  • 0:52 - 0:55
    except that debugging surprises is harder
  • 0:55 - 0:59
    because you don't know how they would not surprise you.
  • 0:59 - 1:03
    Increase precision and automation--next suggestion.
  • 1:03 - 1:07
    In the end, you do have this huge program
  • 1:07 - 1:11
    and you want to be able to find as many bugs as possible.
  • 1:11 - 1:18
    Of course you can have developers read it, review it, test it,
  • 1:18 - 1:25
    but in the end, the time of your developers will always be a precious resource.
  • 1:25 - 1:29
    In other words, you won't have the developers, you won't have the time,
  • 1:29 - 1:32
    and so you'll be pressed to ship anyway.
  • 1:32 - 1:38
    If you can automate these tasks, then resources will be much less of a problem
  • 1:38 - 1:43
    because you can have an arbitrary number of computers doing the checking for you.
  • 1:43 - 1:49
    This calls for techniques such a contracts, assertions, or other forms of specification
  • 1:49 - 1:52
    that can be validated automatically,
  • 1:52 - 1:56
    plus, of course, lots of automated testing that follows.
  • 1:56 - 2:00
    The next step is to reduce complexity.
  • 2:00 - 2:03
    The higher the structural complexity of a program,
  • 2:03 - 2:08
    the more ways there is for some part of a program to influence another
  • 2:08 - 2:11
    and the easier it is for infections to spread.
  • 2:11 - 2:19
    Plus the higher the complexity in a program, the more possible sources for infections there are,
  • 2:19 - 2:22
    and all of this makes debugging way harder.
  • 2:22 - 2:25
    Next step, set up assertions.
  • 2:25 - 2:31
    Every single assertion rules out large parts of the program or of the program state
  • 2:31 - 2:34
    as an infection cause.
  • 2:34 - 2:41
    And the more assertions you set up, the less state and statements do you have to examine
  • 2:41 - 2:44
    in order to figure out where the infection came from.
  • 2:44 - 2:47
    Next thing, test early and test often.
  • 2:47 - 2:52
    The earlier you test, the more precise your specification will be.
  • 2:52 - 2:56
    And the more you test, the more defects you will catch right away.
  • 2:56 - 3:04
    Plus, if you test frequently, you will be able to isolate the change that led to the test failing
  • 3:04 - 3:08
    by building on the past history of successful tests.
  • 3:08 - 3:13
    Next, review your code or have it reviewed by your colleagues.
  • 3:13 - 3:18
    Having your code being inspected by others has been shown again and again
  • 3:18 - 3:25
    to significantly increase productivity, quality, and project stability.
  • 3:25 - 3:31
    Next step, go and analyze the problem history of your project
  • 3:31 - 3:38
    in order to figure out which components have shown risk in the past and which ones haven't.
  • 3:38 - 3:45
    Obviously, components that had troubles in the past would always be the first ones to focus on
  • 3:45 - 3:48
    as it comes to improving quality.
  • 3:48 - 3:53
    Analyze their history, their common features, common causes,
  • 3:53 - 3:56
    and adjust the development process accordingly.
  • 3:56 - 3:59
    Last, learn from your mistakes.
  • 3:59 - 4:02
    Every bug you make is a bug too many.
  • 4:02 - 4:08
    Improve your development process such that bugs are caught as quickly as possible.
  • 4:08 - 4:10
    If a bug escapes into production, make sure it won't happen again.
Title:
What You Can Do - Software Debugging
Video Language:
English
Team:
Udacity
Project:
CS259 - Software Debugging
Duration:
04:15
Udacity Robot edited English subtitles for 06-03 What You Can Do
Fran Ontanaya edited English subtitles for 06-03 What You Can Do
Amara Bot added a translation

English subtitles

Revisions Compare revisions