The Band-Aid Mentality of Fixing Bugs
When debugging applications, do you code it properly or do you procrastinate or rush through it just to get it done?
Disclosure:
I get commissions for purchases made through links in this post.
Developers know when they see a bad piece of code and that comes from experience. As you progress through your career, you'll see some...uhhh...ummm...interesting code. Most developers have egos and need to check them at the door if you want a quality software product.
What's a piece of "band-aid" code?
Band-aids are described when a coder decides to fix a defect quickly as opposed to fixing the defect correctly. The mentality is that they want it off their plate by fixing the problem as fast a possible, which leaves the defect as a quick fix and not a long term solution.
If there is a choice between fixing a piece of code with a workaround or breaking the code into two or three classes to make the code more understandable and manageable, most programmers will go with the workaround just to get it out of the way.
I understand that some defects are cut and dry (like a string not checking for a null), but some workarounds can get hairy and hard to deal with.
In the age of the Internet, I understand everyone is rushed and moving at the speed of thought, but your code should slow down, meaning that when your coding, take the time to optimize and leverage what you already wrote.
How do you detect "Band-Aid" code?
When experienced developers see a bad piece of code, most programmers start to develop an unnatural twitch (just kidding).
Seriously though, this is where the term refactoring comes into play. There are tons of papers and books out there that discuss exceptional techniques on how to refactor bad code.
The only advice I can give are two items:
- Read as much as you can (knowledge)
- Code as much as you can (experience)
I can't provide the experience to you, but I can refer some exceptional books that can assist you in your coding.
One such reference I would recommend for the .NET developers of the world is LosTechies.com's free ebook called 31 Days of Refactoring. Definitely a great read. Small bite-sized topics with examples of code to quickly digest and start using in your own code.
Other books I would recommend are listed below:
- Refactoring: Improving the Design of Existing Code (affiliate link)
by Martin Fowler
- Refactoring: Ruby Edition (affiliate link)
(Not Ruby on Rails, just a prestige class of book)
- Refactoring to Patterns (affiliate link)
Along with the little bit of reading, here is a little bit of advice for "fresh" developers:
- "Rip the band-aid off!"
Quit writing workarounds and refactor your code immediately. You'll be able to sleep better at night knowing your code is written properly.
- If you don't have the time to code it right, when will you?
Of course, I understand that project managers, supervisors, and other managers are breathing down your neck for next week's deadline, but "manage the managers." Just tell them you are making the world a better place with cleaner and more manageable code. ;-) Take the time to "black box test" your code.
- DRY out!
Don't Repeat Yourself! As I said above, leverage code you already wrote and tested. If the code is tested and solid, you won't need to go through bad code/good code phase because you know your routine works. Start building your libraries to have an impact on the finished product. As you build your own library, you'll start to see the power of already tested code...and the process of getting it done quicker.
Bottom-line: Always code as if the person maintaining your code is a violent axe-wielding psychopath who knows where you live (WARNING: Interesting Picture).
Love that quote!
Share your discussion below. How do you handle bad code? C'mon...be honest.
