Continuing with our topic of software professionalism, ala Uncle Bob Martin, we are going to consider the practice of Fearless Coding. While I am writing from personal experience in this matter, I am drawing from Uncle Bob’s packaging of many different principles. Some of them can be found at this presentation on YouTube, should you wish to dig further.
This practice of fearless coding can only exist when you KNOW that you can change existing software without doing any harm. Your changes will introduce only new requirements; it will not break any existing requirements, except those being deprecated by your change.
Have you ever experienced a time when someone says, “don’t modify that code. It is too complicated. Every time somebody touches it really bad things happen. It takes a long time to get it cleaned up again.”
How can you have code like that? You may as well go out of business. It’s your own fault for allowing it to be created in the first place; its even worse that it still exists after being created. There are a number of things that can be done to fix code that is difficult to modify.
- Break it down into smaller components
- Write automated tests for the smaller components and make sure they all pass. Maintain those tests for perpetuity
- Apply sound principles to break the code into maintainable components. If object oriented, use object oriented principles
Sometimes you don’t have to bite the whole thing off at once. Find a section you can split out.
Be willing to throw away your refactored code as the real intention emerges. You’ll learn a lot by taking smaller pieces and optimizing them. Then fit in code based on better patterns and they demonstrate themselves. You’ll know when you see repetitive things happening.
Be fearless to make changes. Find or learn techniques that allow you to be so.
Cheers,
Ben