Refactors and merging projects of Angular 4 into Angular 1.5

Last week I had to sit through a meeting where we were trying to figure out how to merge an Angular 4 app into an Angular 1.5 app.  First off, why?  The original intent was to merge the features of each project into one to create a new product.

Our defense was that we were using the latest, at the time, Angular library and that we had just finished a complete refactor and re-architecture of our entire project that took 2 months.  However, we lost the argument because the other project already had alpha/beta/production users.  What they had failed to do was a refactor, code review, or unit tests for the last year.  They have been working off of prototype code from the very beginning.

After the meeting I asked to have a static code analysis done of both code bases with HP Fortify and SonarQube.  The results were without question in our favor.  Both HP Fortify found 3 errors in our code which turned out to be false positives and SonarQube produced 0 issues, code smells, duplications, etc.  For the other project there were 130 issues with HP Fortify and 29 bugs, 3 vulnerabilities, 231 code smells, and 33% duplication with SonarQube.

Even after the static code analysis was done 4 developers took a look at the code base and it was even uglier than they thought.  Most of them saying they would be embarrassed to have the code base in their portfolio.  The code was hacky and only one developer was working on it for an entire year with no code reviews or merge requests.

Here is the rest of the story.  The project that came up with 0 errors was prototyped with minimal architecting effort, but got to a point after our MVP demo that it needed to be refactored in order to produce a sound and maintainable project.  What the static code analysis was not able to identify was the bad architecting that we originally did.  SonarQube found only 9 issues before our refactor.  I didn’t expect a static code analyzer to find out architecting mistakes, but the amount of difference between our code architecture before and after the refactor was massively different.  That is why we need some code reviews done to ensure that our findings for providing the accurate information to make a decision on our code base merge.

The obvious decision would be to merge our Angular 1.5 app into our Angular 4 app, but there is a business case that might not allow for that timeline, so we have prove our case that our technical solution is a better way forward for the business.

Leave a Reply

Your email address will not be published. Required fields are marked *