Apparently we are quite often doing changes we believe to be refactorings, but that actually aren't. How do we deal with that?This one is easy: It says it right there on the front page of https:// refactoring.com/: "Refactoring is a part of day-to-day programming" [...]
The theory is clear. However, in practice, mistakes happen and accidental side effects slip through. Of course I'm very careful to avoid this, and we have a lot of tests to prevent accidental behavior changes. Yet, I'm not perfect, nor do I know anyone who hasn't been wearing a brown paper bag instead of the Two Hats at some point.
In my experience these mistakes in refactorings are more frequent than breakage from bad merge conflict resolutions for bug fixes. Most of the bug fixes I see are small, localized affairs while refactorings usually touch code in many places. As a result, mistakes in bug fixes are generally easier to spot than in refactorings.
That's why I try to pick back as little code changes as possible, even at the cost of some merge conflicts and somewhat messier code in older branches. Sometimes you cannot avoid a refactoring before a fix. That's fine then, and then we need to pick back the refactoring, too. But most of the time, I can avoid it.
best, Ulf -- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
