Architecture, refactoring or what’s really important

In the life cycle of every project there is a moment when the question of refactoring arises. Engineers want something new, fashionable, and interesting to appear in the project. The business needs to get a new functionality faster and faster. And the project team say they get tired of making changes and need refactoring. Does it sound familiar?

Now before you agree to refactor your system/subsystem, I think you should answer the following questions:

1. Is it really necessary for you?
2. What will refactoring give you?
3. What will be the consequences?
4. What should be done in order not to use refactoring in the future?
5. If you do have to rewrite the code, what will your plan be like?

Is it really necessary for you?

Before you start refactoring, you should thoroughly analyze the design with the aid of an automatic tool, such as SonarQube, in order to assess the existing code base. Make measurements related to performance and collect detailed information about points where it can be enhanced.

Then asses how much time engineers spend on supporting the existing solution and implementing new features. The existing system may not be good for extension; data on labor costs can be retrieved from JIRA/Redmine/TeamCity/TFS. It would also be useful to check how the product owner implements changes, or whether the user stories have changed. In that case you will need to refactor the process and procedures of handling Change Requests.

Find out more at — http://bit.ly/2V02wea

Originally published at www.luxoft-training.com.