The Haunted Codebase. A Software Developer’s Halloween🎃👻🦇
The Secret Developer has had a bad few Halloween experiences. Silent scary standup meetings? They’ve been there and done that.
“This time I think something scarier is happening. This October 31st is frightening. Let me explain why.”
The Secret Developer’s fears
The Secret Developer is scared of a few things. Their code is perfect, so what could possibly be happening this Haloween to bring the monsters out from under the bed.
Phantom documentation
“Missing documentation for essential features in this codebase keeps me up at night. It means every time we go through our legacy code that nobody knows what the functionality should be.
That makes refactoring a particularly scary task.”
Fear: We don’t know what our code should do.
Haunted codebase
“Our codebase has a good number of scary solutions in it. The previous developers have thought nothing of tangling their code up to such an extent that it can’t be untwisted into something understandable.
That is, we don’t have separate services for API calls. They’re bundled haphazardly into weird groupings. Nobody knows what goes where because of the lack of documentation mentioned above.”
Fear: We don’t operate a separation of concerns on our codebase so the code interacts in unpredictable ways.
Haunted codebase
“SOLID? It’s scary that some of our past developers clearly had no idea of what that meant.
I found code that put a business object into a class. Nothing scary there, but it crammed another instance of the object into a property of that class.
To use that object some functionality was contained in the class, some in the instance and some in other properties.
I think it’s haunted because those properties are behaving with a phantom will of their own.”
Fear: Working in a codebase where people don’t know how to code is frightening.
The Dead Future Release
“We spend hours of our life (this job is killing me so is a horror in itself) talking about making our app backwards compatible.
Nobody understands the versioning or the functionality.
I think when it releases the undead are coming out.”
Fear: Our whole project might go bang on the next release. It’s worrying.
Solutions
Don’t fear! The Secret Developer has some solutions to the problems related to this article. Let’s take a look at them:
Documentation:
Document code according to team standards and ensure all developers adhere to what is agreed.
Automate documentation generation where possible.
2. Code Reviews:
Implement a rigorous code review process to catch issues like lack of separation of concerns and adherence to SOLID principles.
Encourage code reviews to share knowledge and improve code quality. Don’t be a jerk in the code reviews.
3. Refactoring:
Allocate time for regular refactoring to tackle technical debt and improve the codebase’s readability and maintainability. Make sure you do it (that would help).
4. Automated Testing:
Implement unit, integration, and end-to-end testing to catch bugs early and ensure the code is functioning as expected.
Try TDD. It’s awesome.
5. Separation of Concerns:
Refactor code to adhere to the principle of separation of concerns, ensuring that different parts of the code have clear, distinct responsibilities.
Organize code effectively using architectural patterns to do so.
6. API Management:
Separate API calls into distinct services or repositories to avoid haphazard bundling of functionality.
Document (of course).
Conclusion
The perfect answer to a situation like this is to roll up your sleeves and improve the code. The Secret Developer has taken up another path:
“My code is perfect. This is all someone else’s fault and they are the monsters I fear at night. Why can’t they work to my standards? They are vampires.”