Ever wonder when you will stop on frequently checking out old code? Revisiting for what reasons you may ask? Just short trips to fix small bugs, re-factor for performance enhancement, do some small expansions to accommodate new requirements, etc. You visit an old code to do all these stuff other than code appreciation. If you are this kind of coder, you are a shame!
This piece of writing will be debatable to most developers. I don’t say we don’t go back to the code we have already checked-in. But at least we should minimize going back.
By checking out old code and doing some modifications (be it intentional or accidental), you are likely to do the following:
- Introduce a bug
- Break a build
- Costing your employer money (for retesting). You should thank that automated testing are in nowadays.
- Forcing others to check out their objects dependent on your code
To test yourself how you fare with creating bugs, rate yourself on how many bugs you create or introduce for every 100 coding task assigned to you. I would always want to stay below 1%. In most cases, it is achievable, unless you are lazy and you don’t get a clue. But the next question now is how will one achieve a bug-creation rate below 1%?
Here is how I usually achieve this and it’s pretty simple:
- Start from the smallest dependencies if possible.
- Understand the problem and coding task very carefully
- Create testing procedures. Be sure you cover all possibilities.
- Code
- Test code using your test procedures.
- You may review/ from steps 2 to 5 before checking in code. Never, ever check-in code if you are not 100% sure you have done steps 2 to 5. If you check in code without the 100% assurance, you just started a problem that will show itself sooner or later. (Some programmers have the habit of checking-in untested code because perhaps they are too slow or lazy to beat the check-in deadline). Others are just not qualified to write code thus they fail on steps 2 to 5.
- Check-in code and never look back.
- If you pass step 7, you can move on to a new coding task.
At this point, there are probably several possible outcomes that I will encounter:
- If there is one bug in my code, then I can say that I probably failed in one of the steps 2 to 5. And it can be said that I have not done my homework well.
- What if there is a new functionality needed that was missed? In most cases, if I was doing a good job on Step 2, this new functionality could have showed up in my radar and could have raised some alarms. But I did not coz probably I am no good and too lazy. In any case, I can go for a new version of the object and leave the old code intact for future deprecation (especially if the code is quite complex and the needed adjustments are just too significant). Else, If I am pretty sure that the changes are just trivial and I’d be able to ensure guarantee on step 6, then it would be logical to check-out the code again and update. But either way, I already failed earlier.
In most cases, if I have been doing a good job on steps 2 to 5, there is a slim chance or none at all that I would re-open and change the code. I love to call this a “fire and forget” coding that has saved me a lot of headaches since I started programming for a living. This isn’t perfection. It is just one way of making things better.
totogamboa.wordpress.com 