When to touch Code and When to Not
It’s always tempting when looking at code to just jump in and start hacking away. You are under time constraints, have other stuff to do, and you just need to get this done. We have all been there, probably in the last week or month! But when is the right time to change code, when not?
For us a rule of thumb has to be TDD. No test(s) no change. Adding a test forces you to think about the issue, to lay it out in your mind, plus it adds to our regression test suite as a nice little by-product. The test exposes the issue or the missing capability.
Now you have tests around it you have probably narrowed down the piece of code you wish to alter. The next step is to decide how to change it. Its tempting for a junior developer to add in lines of code to fix the issue they are tackling. And leave at that. The problem with this approach in many situations (not all) is that you are adding to the technical debt, but not taking away. I always like to try to add something to the code in terms of refactoring forwards, to tidy it up, to move it along, just adding lines of code can eventually lead to a birds nest if you aren’t careful.
So the approach should be:
- Do I need to change anything?
- Can I use anything that I have already here (i.e. can I make this code more DRY)?
- Can I refactor this code now I have solid tests around it to be more elegant and work better with my new additions?
- Are there any other weaknesses I see that maybe I should add tests for?
The best developers in my opinion are those that don’t rush into write code, they are those that want to remove code. That should always be your aim, if you are going to add code then try to remove elsewhere so that overall you arent adding to the ‘tech debt’.
There are cases I see where it would be great to tidy up a piece of code but you have to resist. Because you might not have enough tests in that area to be sure of no impact of your changes, or it might be so tried and tested that its not worth disrupting. We had this scenario with MatrixRates (a magento extension), it went through code reviews and people said change this, change that, but the reality was that the code worked and worked well, was on tens of thousands of sites and actually its beauty was its simplicity and rawness. It never went wrong, yes it had limitations but it was free and to add features/expand would have meant more support, more issues from scenarios.
As a programmer you should be on a constant journey. I’ve been programming now professionally over 20 years, I don’t class myself as an expert, I’m just working my way through all this stuff in the best way I can. So don’t be intimidated. The ability to learn fast is key, as new paradigms and programming languages come/go at a rapid pace. Persevere, don’t go off on tangents, focus on the task in hand, where appropriate putting gates and TODOs as markers to return to later just so you can folllow a single path through.
Whats important really isn’t what you actually know its about how you go about solving problems. Be extremely methodical, resist the urge to write code or jump the gun, and treat testing like your BFF. It will take you a long way.
