This article was originally published on my personal blog "Simplify C++!". Simplify C++! is a blog about modern C++ and Clean Code.
Rules of enga...
For further actions, you may consider blocking this person and/or reporting abuse
My only grouse with re-factoring large and legacy code, is that backporting becomes a big headache. I am a sucker for refactoring in newer projects, but am one of the skeptical few when the project is already RTM.
I understand. Is backporting something you regularly see? In my experience, it is close to impossible in legacy projects, because new functionality builds on basically everything that came before. Taking a single piece of functionality back to an earlier version usually does not pay off.
Yes, Arne. We backport a lot of bug fixes from the current development branch to production branches. Many-a-times, we had to deliver an enhancement required by a customer, and we would code that on a development branch, and then backport it to production branches.
Thanks for posting Arne. I think this writing acknowledges all the things how to efficiently refactor code. Good job! 👍
I can totally relate to this. That's why i prefer to have those very microscopical commits in the VCS. Small changes are easy to name: "remove unused argument from Class.method()", "rename method Class.method() to Class.newName()". It also creates a mental note that this change is safe, but this other was not that safe. Once the tests expose that i broke the code i can quickly review the commits and revert the one i think broke the tests.