This question already has an answer here:
I am currently in a project where one of my developer colleagues constantly refactors stuff on every ticket he's doing. We are using agile methodologies. I know that refactoring is a good thing to do while solving some issues, keeps the codebase nice and clean, but my question is, what's the limit, how many files should one be touching at max? Can too much refactoring bite us on the long term?
Sometimes it feels like he could be introducing bugs (although the system is heavily tested) and that it makes the review process quite cumbersome; reviewing changes in 60-70 files when the original change should have affected only about 10-20.
On the project the tickets we are getting are quite small, usually no more than 10-20 files need to be touched, and this developer is averaging 50 or so. It feels wrong, and I haven't found a way to convince him that it's not. He says everything is tested, so all changes only improve the codebase. Finally, I am assuming that this refactoring could also be slowing him down, cause he just changes so many damn stuff all the time ! :D
Any thoughts ?
My personal view is that refactoring should be done, but it should usually be limited to the classes that are changing for the ticket anyway, and should a need for a bigger refactoring occur, it should be a ticket itself. In some cases, I find myself not even changing small stuff, cause "I've refactored enough for this ticket as it is.", it feels like when I reach the refactoring limit I've got set in my mind, I just stop making any non-necessary changes to the codebase and only focus on wrapping up the ticket..
Edit: I've come to realize from reading the responses and similar questions on programmers stackexchange (that I just discovered, what a lovely place !) that my main problem is that what I described is a single commit. I need to tell everyone that that are free to introduce refactoring but make sure they keep it in separate commits to ease the reviewing process.
Edit: Another aspect that I have found to be problematic is merge conflicts. These refactorings end up costing time to other members working on same pieces of code every now and then. Nothing substantial, but if everyone on the team made so much refactoring we would surely have many more merge conflicts. Not saying that this is the end of the world, just putting it on the table.