Refactoring large parts of a complex software system can cause a lot of troubles. And it is difficult. And I am always afraid to do it. But we have a lot of automated unit tests, integration tests and user acceptance tests in my current project, so most of the time I am pretty confident that I can make it. Without destroying any major feature.
Some days ago, I had a discussion with my co-workers whether we should start a large refactoring or not. Some were against it because of our tight schedule. We are committed to deliver working software at the end of the sprint, and we are committed to deliver the selected sprint backlog. And refactoring that part of the program would affect a lot of existing functionality, and all the committed user stories for the sprint.
After this discussion I really was not sure anymore if the refactoring would be a good idea right now. But it was absolutely necessary. We had a lot of code duplication. Some classes were used but not needed anymore, because the functionality could have been added to their base class. Responsibilities of one object were distributed over several classes.
Yesterday, despite all doubt, I started the refactoring. Today before noon I had outlined the basics so my co-workers could build on it. Shortly after that all unit- and integration-tests were green again. I started tomcat and tested the Application - all existing functionality still worked.
Implementing the current user story was really easy using the new design, and the next will be easier than before the change too. The refactoring was really successful - Everything still works and we have earned a quick win. And there were so many good arguments against starting it.
It’s all about courage. (One of the 5 values)
You might be also interested in… Learn more about how I can help you save money and earn money by courageously improving your software quality.