{"id":1207,"date":"2014-10-07T15:54:52","date_gmt":"2014-10-07T14:54:52","guid":{"rendered":"http:\/\/qualilogy.com\/en\/?p=1207"},"modified":"2014-10-07T17:02:40","modified_gmt":"2014-10-07T16:02:40","slug":"legacy-application-refactoring-sqale-plugin-1","status":"publish","type":"post","link":"http:\/\/qualilogy.com\/en\/legacy-application-refactoring-sqale-plugin-1\/","title":{"rendered":"Legacy Application – Refactoring with the SQALE plugin (I)"},"content":{"rendered":"

\"Application<\/a>In order to estimate the cost of refactoring our Legacy application, I will use the plugin SQALE of SonarQube, more usually employed to measure the technical debt.<\/p>\n

We have already presented<\/a> this plugin with a PL\/SQL Legacy application. So just remember that the SQALE plugin is based on the SQALE quality model<\/a>, and I will also add, on a method to adapt the model by aligning it with various business objectives, the technology or the contexte of the application. <\/p>\n

SQALE and Legacy applications<\/h2>\n

Today, any application over 3 years is considered ‘Legacy’, especially if it does not have unit test coverage. In this case, ‘Edit and Pray’<\/a> or ‘Change and run’, explains Michael Feathers in his book \u00ab Working Effectively with Legacy Code \u00bb.<\/p>\n

So you understand that we will not use the SQALE model in the same way for a J2EE application that is three years old, or our Word 1.1a application in C that was developed 20 years ago, or an even older Cobol application that has gone through the hands of several different teams, and some possibly offshoring.<\/p>\n

We must also consider the type of application: here we have an office software sold by an editor software, and it’s not at all the same as a J2EE application developed in-house to meet business needs or based on a software package such as SAP. For example, our application is written in C and uses no database: factors like ‘performance’ and ‘security’ will not have quite the same weight as a traditional application to manage the business of a company.<\/p>\n

SQALE and the monitoring of technical debt<\/h2>\n

Another factor to consider: as explained by Freddy Mallet from SonarQube in this video<\/a> (in french) : \u00ab\u00a0Technical debt means to avoid waking up after 5 years with a code with which we can no longer do anything without it costing us an arm and a leg \u00bb.<\/p>\n

A common use of the plugin SQALE is to monitor and control the technical debt over the versions, in order to prevent it to go beyong a threshold where it starts to become unbearable and too expensive.\u00a0Or, as explained in this post<\/a> : \u00ab don’t start mopping the floor before you\u2019ve plugged the leak \u00bb.<\/p>\n

In our case, we only have a single version, so I will again point out that our use of the SQALE plugin is specific to our goal of evaluating a refactoring effort, without a personalized model but proceeding directly with ‘out of the box’ results .<\/p>\n

In the context of this article, I will present these results in order to illustrate the approach to estimate the cost of refactoring a Legacy application. Estimation done ‘a priori’, even before to consult the project team or the management about this refactoring, but with the intention to list some elements to present during a future meeting.<\/p>\n

SQALE in the SonarQube dashboard<\/h2>\n

I configured my own dashboard in SonarQube with a widget to display the following data from the SQALE plugin:<\/p>\n

Figure 1 \u2013 SQALE data on the technical debt of our Legacy application
\n<\/em><\/strong><\/p>\n

\"Donn\u00e9es<\/a><\/p>\n

1 238.7 days to reduce the technical debt. With a rate of 18.5 working days per month<\/a>, this represents 69.4 months and, for our team of 5 people, 13.9 men\/months.<\/p>\n

So it takes almost 14 months to our project team to overcome this technical debt. Needless to say that this is not acceptable for the management: it means to stop any development, any new release for over a year. No customer, no user would agree to such a decision.<\/p>\n

However, our goal is not to eliminate 100% of that debt, but to make an effort to reduce it so that the burden of the debt becomes acceptable, and the corresponding reduction in maintenance costs becomes greater than the cost of refactoring. Indeed, the decision whether to make a refactoring is usually based on a ROI (Return On Investment), and having the gains in maintainability exceed the cost of refactoring.<\/p>\n

Is it possible to consider a reasonable effort, with limited but specific actions, and a return on investment? This is what I will look with other data configured in my widget.<\/p>\n

First, I see that the ‘SQALE Rating’ is equal to ‘B’. This shows the weight of technical debt in relation to the whole application. Another SQALE widget in the SonarQube portal gives me the distribution of the technical debt on different files.<\/p>\n

Figure 2 \u2013 File Distribution by SQALE Rating<\/em><\/strong><\/p>\n

\"Distribution<\/a><\/p>\n

We have 12 files with a very high technical debt, and if I list these files, I will find some programs previously identified<\/a> as the most complex, the largest in number of lines of code (LOC) and\/or with\u00a0very complex and large functions.<\/p>\n

Figure 3 \u2013 Highest SQALE remediation costs<\/em><\/strong><\/p>\n

\"Highest<\/a><\/p>\n

Another way to check the distribution of technical debt on all application files: the Bubble Chart. I love this one. I can choose any metric I want and cross them:<\/p>\n