Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
13 Cards in this Set
- Front
- Back
|
Debugging |
A process where a programmer discovers and fixes areas where a program or system is not working properly |
|
|
Bugs or buggy code |
The errors in the program or system that are producing the incorrect results |
|
|
Software updates |
Often used to fix bugs in programs |
|
|
Input Error
|
One of two main types of software problems Refers to when incorrect data or configuration is introduced to a working system |
|
|
Logical Design Error |
One of two main types of software problems Refers to when the system or program has unpredicted or invalid results due to how it was designed |
|
|
Debugging Guideline Steps |
1) Reproduce the error 2) Determine the exact problem 3) Eliminate any 'obvious' causes 4) Separate working parts from non-working parts 5) If you get stuck, don't panic, trace back and re-assess 6) While working through the code, predict what should happen and test your hypothesis. |
|
|
When debugging Images and Hyperlinks... |
...make sure references are spelled correctly |
|
|
When debugging Attributes and CSS issues |
...check that you have the proper form |
|
|
Redundancy |
A method for solving hardware issues where multiple computers or systems work on the same task. The thought is that if one machine goes down, the others will continue the work. |
|
|
Ideal Goal in Programming |
To design a program that accounts for all possibilities and works perfectly |
|
|
The reality in programming |
Software becomes complex quickly and many people work on only one piece |
|
|
Fail-soft |
One of two design strategies that programmers can choose to implement in case of some sort of serious un-testable problem (like a natural disaster). Usually reserved for software that is performing some sort of critical task. In this strategy, the software will continue to operate, possibly losing some functionality |
|
|
Fail-safe |
One of two design strategies that programmers can choose to implement in case of some sort of serious un-testable problem (like a natural disaster). Usually reserved for software that is performing some sort of critical task. In this strategy, the software will stop operating in an attempt to stop further damage |
