With debugging it isn't quite as simple though.
When I first started programming I would sometimes write the program out on paper, and read through it while keeping track of all the variables. Being able to read code while keeping a mental list of what is happening is valuable when working in a group, but this skill is sometimes neglected due to the ability to run it in a debugger and watch certain variables.
My ideal development strategy is as follows:
1. Write the unit tests as a working specification document. This helps to identify flaws in the intended interface early in the development process.2. Create mock objects that emulate the behaviour of the intended module, with fixed input/output. This allows you to verify that you have the necessary data at each step, and also allows you to verify the algorithms without external dependencies.
3. Implement the object.
This strategy leads to loosely coupled / tightly cohesive objects, which are easier to verify with testing and easier to isolate issues when debugging.
A similar strategy can be followed when debugging the code of your team members. Debugging manually is a very time consuming task, regardless of whether the debugging is done through code reading or with a debugger. Use this time more wisely and develop test cases that mirror the analysis you do during debugging.
In reply to Re: Are debugging skills atrophying?
by imp
in thread Are debugging skills atrophying?
by dws
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |