Working with an unusable codebase

Question

Even though this is not a real code question I still ask it here. Because I wonder: how do you guys work in a codebase that is SO BAD that every little change breaks multiple features and classes? That every little change you make or attempt to refactor makes EVERYTHING blow up in your face.

Think about: circular dependency, double includes (C++), plain integers instead of enums for switches, in-house library dependent on the app that was initially build onto that library, ghost threads starting in the library, loops starting not in the main but in a library class doing black magic in the background, singletons in the library called ALL OVER the place in the application, long and incomprehensible switch statements, inconsistent variable naming, very bad spelling in the variable names and the list goes on and on.

Everytime I want to add a feature I see that the foundation for that feature is incomplete, unstable, unmaintainable and not fit for extension. Every time I look at the code I get stuck almost instantly and it seems that adding a feature is impossible without refactoring EVERYTHING.

I could hack the feature into the code but that would just come back and bite me in the ass, so I simply refuse to do that even though other team members don't seem to care about it themself. I think that attitude has made the codebase as abysmal as it is.

I'm a student and this is for a school project, so as you might have picked up: I'm absolutely not a class-A programmer, I'm a noob but a noob with the uncontrollable urge to make something clean, elegant and reusable.

It doesn't seem like a full refactor is an option, the people are 100% reluctant to do it and it's me against 29 others. Every time I start to look at the code I feel the urge to hit my face in the wall, eat my face, delete the project and never look at it again out of boiling hatred, frustration and repulsion of the remarks from other saying "but it works now, I don't see the problem". How do you handle stuff like this? I could really use some tips for my sanity.

Answer 1

Refactoring is a good thing, but there is an underlying assumption in order to do that - there are plenty of good tests.

Does your code-base have enough unit tests that clearly outline the responsibilities of each method? If not, you ought to start writing them. Donot start with a big bang.

Identify a pilot functional piece - and write thorough unit tests for them. A guideline to gauge if the tests written are sufficient enough is code coverage (although it is just a guideline). Now, employ refactoring on the functional piece, keeping in mind the SOLID principles.