In the last two years I have worked with a poorly written codebase of nearly 40K lines of code. Over that time I have made many small refactorings to improve it and made some bigger, as time permits.Unfortunately, I still view the codebase as poorly written.What's your experience? Do you think many small fixes can take me somewhere, or I have to stop and allocate a big chunk of time to fix things (of course, management won't be happy if I do this while we're working on the current very important new feature).
Small refactorings on a poor codebase?
refactoring;legacy
My take is that refactoring is included in delivering new features. I assume that leaving good code behind me is an expectation of my job and seniority.Therefore, in a case like yours, I would refactor as heavily as needed all the parts that are affected by any change, and include refactoring times in the estimates I give.If your management does not understand the concept of technical debt—and the costs of repaying it—or does not support a reasonable amount of refactoring, you might be very limited in your current position.You should never be asked to deliver crap code, within reasonable limits. If you are, then the standard retort is Why don't you hire a junior programmer to write it? They will surely cost less than me.