top | item 28770599

(no title)

bumbada | 4 years ago

This is like telling a poor person: Just earn a million dollars!

Then you can try with an smoker: Just don't smoke!

Finally you can tell an obese person to loose weight.

They are such high level statements that it is completely useless advice without implementation details.

Neither me or anyone on my team write significant bugs. We spend a very small part of our time dealing with bugs. But for this lots of knowledge, discipline and practice is needed.

You can fill several books just with that knowledge alone.

Rereading your code for me is completely useless. When I was a kid I reread code for days without finding the bug because I just make the same (wrong and most of the time subconscious) assumption over and over again. Then I learn better strategies.

A simple tool that checks for wrong assumptions finds those bugs in seconds.

You can log your bugs so you identify recurring patterns and can correct those patterns.

With just a team of three, I wrote a tool that gave an error for any "one line if" without parenthesis after fixing the nth time the recurring bug: People will write a one liner if without parenthesis and then a year from that will add an additional line to the if without adding a parenthesis because they were just so focused in the new problem they just could not see anything wrong while rereading the indented line.

We even use statistical Bayesian analysis of code that automatically highlights any code that goes against the style of her author. In that code she is not experienced and could make the wrong assumptions so must be careful.

Asserts everywhere in developer code that are automatically eliminated in production code(but remain in developer). We assert everything because bugs just pop up from the asserts again in seconds.

Also incremental tests between revisions is extremely useful. Your test work flawlessly in last revision, you changed 20 lines. It doesn't work, the error is in those lines. The smaller the increment, the easiest to find the problem.

Those things are obvious for experienced programmers, but for other people could be magic and sorcery, because there are many details needed to make it work.

discuss

order

No comments yet.