On a lighter note, bad code generates ample employment opportunities.
- One of the many good developers needs to fix the bad code.
- One or two senior developers need to review the code and ensure it does not become bad again.
- The bad programmers (the stars who wrote the jumbled mess of logic) may need to be consulted from time to time to make some sense out of the gibberish.
That said, we all have been there. We tirelessly burn the midnight candle, trying to close a particularly painful bug and we come across a code section, the root cause of the problem. As you try to make sense of the spaghetti — an impossible-to-read, jumbled mess of logic with zero comments for the umpteenth time, you curse under your breath.
This is the wrong way to begin. After all, all of us, at some time would have written bad code. Every other developer on this planet creates security flaws, misaligns UI elements, and more at least once in his life. It is not that he is a bad developer. He is just human.
And the way you respond to bad code has a lot to do with your future roadmap as a good developer. Good developers leave aside any personal or tribal vendettas and get into a deeper understanding of the code rather than pour their wrath on the unfortunate developer who wrote the code.
Good developers avoid subjectivity and give constructive, objective criticism to bad code so that it does not repeat again. They convert it into a learning and sharing opportunity so that everyone benefits in the process.
And here are some ways in which good developers deal with bad code.
1. Identify the problem
Approach the problem with curiosity and empathy for the person who wrote it. The issue with code, in general, is that there are multiple ways to write it and no way is the best way. So, before you evaluate the code, try to find out the reasoning behind the code. Put yourself in the other developer’s shoes and identify the problem statement.
Too often, programmers are stubborn. They do not like to be told of their mistakes. The correct way is to empathize with the person and find out what makes them write such rampant GOTOs, such deeply nested switch statements, and such obtuse naming in the first place. You will soon get the reasons.
2. Ask prudent questions
Once you have established the problem with the code, the next step is to sit with your colleague and ask deeper questions. The key here is prudence. Your best bet is to ensure that the question-answer session does not degenerate into a brutal Spanish Inquisition.
By asking logical questions, you are not only consolidating your understanding of the problem, but you are also allowing the other developer to self-identify his errors and teach him the right queries, he needs to ask himself every day before writing code. By asking questions, you are also showing that you are open to his point of view. When your colleague feels respected, they are less likely to get defensive.
3. Curb your rewrite instinct
Writing high-quality code takes more time upfront than poorly written code. Sometimes, it can make business sense to “get something out the door” faster. Kimber Lockhart, in a presentation as part of a hack summit says that one of the biggest mistakes developers do to address bad code is to rewrite the code again. Rewriting code is not an answer to bad code most of the time. There are a lot of questions to be asked before taking this step.
Prioritize the code. What needs to be fixed first? Can we live with other portions of the code?
Encapsulate the bad code. Keeping the old code running but keeping it separate from the new code by wrapping it in a module will mean no one else can add to it except to fix it. The old code can still be called upon, but encapsulating it keeps the bad code from spreading.
4. Lastly, be humble
If you have fixed the code, don’t let your ego play you through. Don’t spam the entire team with emails. Don’t scream over the rooftops at every opportunity. You are also not infallible. You can also end up in the same shoes and when that happens, you need everybody’s help and support. Never forget that.
Of course, that does not mean, you should not educate others and share your pearls of wisdom. You need to promote a supportive environment with your colleagues and improve the overall output of your team. However, there is a blurred line between sharing knowledge and patronizing knowledge, and you should ensure you never cross that line for the well-being of everybody including yourself.
So, in short, you approach bad code with an open mind, you learn, you improve and then you educate others to improve.
https://medium.com/gitconnected/4-strategies-for-dealing-with-bad-code-57ed7a33d726
