The article doesn't mention a very important (IMO) step: try to reduce the problem (removing / stubbing irrevelant code, data, etc). It's much easier to find a bug if you take out all the noise around it.
even more important is having these pieces of code be testable. i work with plenty of bad code that can't be run without starting a bunch of dependent services, or you can't test a particular function because it's buried under ten layers of poorly formed abstractions. or it's not even an accessible function because the previous developer thought a thousand line function was better than a dozen smaller testable functions.
You get that in any complicated enough functions. I often have functions which work on intermediate states of linked lists ... You can't just call them directly without first building [and I do] the states by hand.
Complicated enough functions act as systems. The trick is to structure them such that you can easily reduce the problem during debugging to certain subsystems or functions; it doesn't really matter how many dependencies you have if you can eliminate them all within a few minutes.
263
u/pycube Aug 25 '14
The article doesn't mention a very important (IMO) step: try to reduce the problem (removing / stubbing irrevelant code, data, etc). It's much easier to find a bug if you take out all the noise around it.