Reengineering of a Legacy application and how SonarQube can help us.
This will be the last post of this long series about refactoring and reengineering a Legacy application. I hope you did enjoy it!
Reengineering of a Legacy application: how SonarQube can help.
Why it is essential to define precisely the objectives of a reengineering, and some other important points.
A simple formula based on the Technical Debt, in order to estimate the ROI of the refactoring of our Legacy application.
Following the previous post about the presentation of the SQALE plugin in the SonarQube portal, let’s see how to use these data in order to build some action plans.
In this post, I will present some data from the SQALE plugin in the SonarQube portal, and how we can use this plugin to estimate the effort of refactoring our Legacy application.
We built a formula to estimate the effort to write characterization tests on our Legacy C application, with the goal of transferring the knowledge to another team, or during an outsourcing.
What about our results? What kind of objections could we face? What would be an acceptable action plan?
We want to write characterization tests on our Legacy C application, with the goal of transferring the knowledge to another team, or during an outsourcing.
What should be the scope of this ‘characterization’? When can we consider that our test coverage is sufficient? Is it possible to quantify the effort it represents?
Following of our previous post about characterization tests, for our Legacy C application.
Back from summer vacations and back on this series about Legacy code. In this post, we will talk about the importance of unit testing in order to understand and a Legacy application, before to start any change.