Junilu Lacar wrote:I think the best way to approach this is to capture all potential improvements (use a keyword in the comments of your code that the entire team will agree on and use, e.g. #TODO:) during the "initial" development sprints. Scrum master/PM should then turn it into lower priority tickets as you go and then have at least one more "refactoring" sprint(s) only for these tickets.
Ouch. You just described what many practitioners would call an anti-pattern. Refactoring is best done as soon as you get tests to pass, which should be done frequently and incrementally. This (what you described) is more like a way to ensure that refactoring gets pushed to "later when we have more time," which of course you only do when, as you say, you have already been bitten (usually by a P1 in production).
This kind of misunderstanding of what refactoring is is what I was afraid would result from the recommendation to wait until you've written all the code to refactor. In my experience, that "big bang refactoring in the end" approach just gets you in more trouble than it supposedly saves you; it's usually much more costly than incremental and in-the-moment refactoring.
In my opinion, larger scale refactoring efforts that require their own "tickets" (ugh) should be reserved for legacy code that you have to maintain. Certainly, spending some time refactoring and fencing in legacy code with characterization tests is a good and prudent practice.
This way, you will not go too far and start attacking "theoretical" problems, but identify and fix components that have actually bitten you along the way.
Sure, there's a chance that inexperienced folks get too carried away and get too "theoretical" about what should be refactored and how it should be done but in general, if you keep with the Four Rules of Simple Design, you really only need Rename, Extract, and Compose Method most of the time. Almost all other refactoring techniques are just one or a combination of these three applied to a specific set of conditions. I have found Rename, Extract, and Compose Method to be sufficient for 80% of the refactoring that I need to do "in the moment."