What are some good strategies to fix bugs as code becomes more complex?

Question

I'm "just" a hobbyist programmer, but I find that as my programs get longer and longer the bugs get more annoying--and harder to track. Just when everything seems to be running smoothly, some new problem will appear, seemingly spontaneously. It may take me a long time to figure out what caused the problem. Other times I'll add a line of code, and it'll break something in another unit. This can get kind of frustrating if I thought everything was working well.

Is this common to everyone, or is it more of a newbie kind of thing? I hear about "unit testing," "design frameworks," and various other concepts that sound like they would decrease bugginess, make my apps "robust," and everything easy to understand at a glance :)

So, how big a deal are bugs to people with professional training?

Thanks -- Al C.

Answer 1

The problem of "make a fix, cause a problem elsewhere" is very well known, and is indeed one of the primary motivations behind unit testing.

The idea is that if you write exhaustive tests for each small part of your system independently, and run them on the entire system every time you make a change anywhere, you will see the problem immediately. The main benefit, however, is that in the process of building these tests you'll also be improving your code to have less dependencies.

The typical solution to these sort of problems is to reduce coupling; make different parts less dependent on one another. More experienced developers sometimes have habits or design skills to build systems in this manner. For example, we use interfaces and implementations rather than classes; we use model-view-controller for user interfaces, etc. In addition, we can use tools that help further reduce dependencies, like "Dependency injection" and aspect oriented programming.

All programmers make mistakes. Good and experienced programmers build their programs so that it is easier to find the mistakes and restrict their effects.

And it is a big deal for everyone. Most companies spend more time on maintenance than on writing new code.

Answer 2

Are you automating your tests? If you do not, you're signing up creating bugs without finding them.

Are you adding tests for bugs as you fix them? If you do not, you are signing up for creating the same bugs over and over.

Are you writing unit tests? If not, you are signing up for long debugging sessions when a test fails.

Are you writing your unit tests first? If not, your unit tests will be hard to write when your units are tightly coupled.

Are you refactoring mercilessly? If not, every edit will become more difficult and more likely to introduce bugs. (But make sure you have good tests, first.)

When you fix a bug, are you fixing the entire class? Don't just fix the bug; don't just fix similar bugs throughout your code; change the game so you can never create that kind of bug again.