I inherited an existing code base for a product that is reprehensibly sloppy. The fundamental design is woefully inadequate which unfortunately I can do little about without a complete refactor (HIGH coupling, LOW cohesion, rampant duplication of code, no technical design documentation, integration tests instead of unit tests). The product has a history, high exposure to critical "cash-cow" clients with minimal tolerance for risk, technical debt that will make the Greeks blush, VERY large codebase and complexity, and a battle-weary defeatist approach to bugs by the team before me.
The old team jumped ship to another division so that they have the opportunity to ruin another project. It is very rare that I experience a Technical Incompetency Project Failure as opposed to a Project Management Failure but this is indeed one of those cases.
For the moment I am by myself but I have a lot of time, freedom of decision and future direction and the ability to build a team from scratch to help me.
My question is to gather opinion on low impact refactoring on a project like this when you have some free time during the functional requirements gathering phase. There are thousands of compiler warnings, almost all of them unused imports, unread local variables, absence of type checking and unsafe casts. Code formatting is so unreadable and sloppy that it looks like the coder suffered from Parkinsons disease and couldn't control the amount of times the space bar was pressed on any given line. Further database and file resources are typically opened and never closed safely. Pointless method arguments, duplicate methods that do the same thing, etc..
While I am waiting for requirements for the next feature I have been cleaning low-impact low risk things as I go and wondered if I am wasting my time or doing the right thing. What if the new feature means ripping out code that I spent time on earlier? I am going to start an Agile approach and I understand this is acceptable and normal to constantly refactor during Agile development.
Can you think of any positive or negative impacts of me doing this that you would like to add?
Best Answer
Firstly I'd like to point out that unit tests are not a replacement for integration tests. The two need to exist side-by-side. Be grateful that you have integration tests, otherwise one of your small refactorings could well make one of the low-tolerance cash cows go ballistic on you.
I would start to work on the compiler warnings and unused variables and imports. Get a clean build first. Then start to write unit tests to document the current behaviour, then start the real refactoring.
I can't really see any negative impact. You will gain a lot of deep understanding of the code base, which will help with bigger refactorings. It is almost always preferable to refactor than to rewrite, since during refactoring your still have a working product, whereas during the rewrite you don't. And in the end the sales of the product have to pay your salary.
Once the requirements are starting to come in, I would use what I call the spotlight approach. Do the usual agile thing (prioritize, then cut off a small slab for an iteration, and work through that) and leave quite a bit of time for code improvements. Then refactor where you are working anyway. Over time this will cover wide areas of the code base without you ever having to venture into areas where you would have difficulty justifying to management why you are working on that part of the code.