We have seen in the previous post how to initiate a reengineering with SonarQube, starting with a functional redistribution and a re-design of our application.
Now we can go down a little deeper into the code to identify flows of treatments that would be good candidates for a restructuring. Continue reading
We defined our reengineering project as rewriting our legacy application in a new language or migrating it to a new technology, as opposed to a refactoring which involves reorganizing the code and to correct certain defects in order to make it more maintainable and reduce its technical debt.
We saw different plans of refactoring more or less ambitious, with the help of SonarQube and the SQALE plugin, from the resolution of the most critical defects to a reduction of the technical debt to a ‘A’ level (SQALE rating ) .
However, for the same Legacy application, is it more interesting to carry out a reengineering project or ‘just’ refactoring? Continue reading
A reengineering does not always mean in everyone’s mind, rewriting our Legacy application into another language generally more recent, but it is nevertheless the option we chose.
When it is ‘only’ about reorganizing the code to make it more maintainable, but without porting it onto a new hardware or software platform – such as migrating a Mainframe Cobol application to a Unix architecture – I prefer to talk of a refactoring.
I remind you that this blog has no academic ambitions, so I will not worry about meticulously exact definitions, which lead most often on quadripilotectomic (1) discussions from specialists who have nothing else to do than gossip on any comma. Continue reading