I have been consulting for a company say X, the last few months. X is one of those companies that has a product used by several clients, with approximately 100K transactions per day, but with code that has become unmaintainable, very hard to make changes. I got a call from them, asking for my services in improving the performance, migrating to the cloud, moving their application to microservices architecture and building a team.
Having been there, done that, I always get into these consulting assignments with not a pinch of salt but bagful of salt.
The application has been built by a number of people in the past, passed on to so many others and now being maintained and worked upon by few hapless developers. It’s a familiar story in software development. Isn’t it?
Experience has always taught me to be a silent observer during the start of these assignments. So I understood in a no time about the nature of the application.
- It didn’t have a proper version control mechanism. SVN was being used as recycle bin. So no Version Control strategy
- No MAVEN/GRADLE. Yes you read it right!!! Every jar file was manually downloaded and copied in the project. I didn’t want to get into the Whys? of this
- ZERO test cases. I don’t get surprised at all these days when I come across applications with no test cases. I have long before come to accept that it requires a certain amount of skill and maturity from developers and managers to understand the importance of having test cases.
- No automated builds/deployments. Every two weeks application was deployed manually in all the servers in QA and production environment
- Monolith application, with 400MB of WAR file built and deployed
- Spring application with framework concepts of Spring being used/abused extensively.
Now getting inside the guts of the application, here’s what I found.
- There are approximately 700 JSPs.
- Each JSP has 500 lines of code on an average. It’s a spaghetti of jQuery, JSP scriptlets, CSS and HTML code very hard to read
- Tens of thousands of classes
- The best is here. Each class has on an average 5000 lines of code. The longest class had 18000 lines of code. And there were easily a hundreds of such classes. During my course of stay, when I set up Git and tried to open one such class, GitHub politely refused to open saying “It’s too long to open”
- Code written in Java 8, but not even a single class has any feature related to Java 8 used.
- Oh, duplication of code, thy name is X
It takes a gargantuan effort to streamline these kind of applications. One of the things, I have learnt over several years of coding and personal startup experience is maintaining the quality of an application is a never ending and continuous task. One needs to be constantly conscious about the way the application evolves and have a strong pulse on the quality.
The pressure to meet the deadlines are too much for a developer to think about the quality. After sometime, your focus shifts to just delivering what’s required and quality takes a backseat. The bitter truth is it comes back to haunt you after sometime. That’s why the wisest have said, Karma is a bitch
Inspite of these shortcomings, the deployment infrastructure was the saviour which held this whole application together. But it was a double-edged sword. Let’s talk about this in the next post. In the subsequent posts, I will talk about how we went about solving some of the issues.