Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
JavaRanch.com/granny.jsp
The moose likes IDEs, Version Control and other tools and the fly likes SonarQube in Action: Legacy code Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCM Java EE 6 Enterprise Architect Exam Guide this week in the OCMJEA forum!
JavaRanch » Java Forums » Engineering » IDEs, Version Control and other tools
Bookmark "SonarQube in Action: Legacy code" Watch "SonarQube in Action: Legacy code" New topic
Author

SonarQube in Action: Legacy code

Burk Hufnagel
Ranch Hand

Joined: Oct 01, 2001
Posts: 814
    
    3
Just noticed I keep referring to Sonar instead of SonarQube - my apologies.

To the question though, do you see SonarQube as a good tool for monitoring the health of legacy code as we work to clean it up? Or, is it more suited to new projects where we can use it to help keep things from getting bad in the first place?

Thanks for your insight,
Burk


SCJP, SCJD, SCEA 5 "Any sufficiently analyzed magic is indistinguishable from science!" Agatha Heterodyne (Girl Genius)
G. Ann Campbell
Author
Ranch Hand

Joined: Aug 06, 2013
Posts: 33
    
    5
I'd flip your "or" to an "and" and say yes to both.

First, I like to run legacy projects through SonarQube even if I'm told that it's a zombie app that we won't be doing much maintenance on. Every year managers and executives make decisions about which applications to continue to maintain and which to sunset/replace. I believe that having an abstract understanding of the quality of an application helps them make more informed decisions.

Another reason I like to analyze legacy applications is because it gives the developers' arguments more weight when they (we) say that an app is "hard" to maintain. I know it depends entirely on your relationship/trust with management, but I'm afraid that sometimes when you say an app is hard to work on it sounds like sandbagging or whining. Give them numbers to back yourself up, and they can see that you're not lazy, the app really is problematic.

But back to your original question: analyze legacy apps for monitoring while you work to clean it up? Yes, absolutely. If you've been given time to do this kind of work (and talking the business into that without having already shown someone some numbers can be challenging) then I think you'd absolutely want to use SonarQube to identify a) exactly the scope of the problem and b) where to start. And once you've started, why not use SonarQube to give everyone the warm/fuzzies about the progress you're making?
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 30404
    
150

I work on applications that are between 1 and 11 years old. Whenever I train a new team member, one of the things I cover is the quality across applications. In particular, the code coverage. I explain that it is important to know the code coverage for the code you are changing so you know what kind of safety net you have. I also explain which apps have consistent coverage and which have spotty (hit or miss coverage.) This logic easily extends to other quality metrics. Looking at the codebase in SonarQube tells you how careful you need to be about dragons surprising you when you touch the code.

Also, SonarQube lets you set warning/error messages based on incremental changes to quality. For example, show a warning if changed files in a project has more than X violations. This lets you triage. Ok. Maybe there 40 blocker issues in the codebase. You can make sure that no new ones are introduced. This is better than saying there can't be more than 40. Because if you clean up 5 and introduce one new one, SonarQube will still show the differential as bad.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Patroklos Papapetrou
Author
Ranch Hand

Joined: Aug 06, 2013
Posts: 32
    
    5

Hi Burk

I totally agree with both answers given.
Just my two cents from my so-far experience. The first thing I do when I join a legacy system is to analyze the code with SonarQube, not necessarily because I want to start immediately improving the quality. I want to have an overall idea of how bad / or how good is the current quality status, discover anti-patterns ( for instance many issues of the same rules ) and see where are the most dangerous parts. Now , if you plan to clean up a legacy system then SonarQube SHOULD BE your first thought. And even if you want to change only some parts of the source code ( let's say only a module ) you can easily track the quality progress only for that module without analyzing the whole project. One of the flexibilities of SonarQube


Follow me on twitter ( @ppapapetrou76 ) or see my linked profile and connect with me
You can slso subscribe to my technical blog
Burk Hufnagel
Ranch Hand

Joined: Oct 01, 2001
Posts: 814
    
    3
G. Ann Campbell wrote:I'd flip your "or" to an "and" and say yes to both.

One of my favorite answers. I thought SonarQube might work well in both instances, but it's good to get an expert's agreement.

G. Ann Campbell wrote:First, I like to run legacy projects through SonarQube even if I'm told that it's a zombie app that we won't be doing much maintenance on. Every year managers and executives make decisions about which applications to continue to maintain and which to sunset/replace. I believe that having an abstract understanding of the quality of an application helps them make more informed decisions.

This sounds like a great idea and, if we're already running SonarQube, there's not much extra work involved in getting the legacy project set up.

G. Ann Campbell wrote:Another reason I like to analyze legacy applications is because it gives the developers' arguments more weight when they (we) say that an app is "hard" to maintain. I know it depends entirely on your relationship/trust with management, but I'm afraid that sometimes when you say an app is hard to work on it sounds like sandbagging or whining. Give them numbers to back yourself up, and they can see that you're not lazy, the app really is problematic.

At a previous company, I worked on a project that got so hard to maintain that the business people noticed and decided to give us six months with no new features or enhancements so we'd have time to clean things up. When we were done they saw that it was better, but I wish we'd had SonarQube then, so they'd have understood the problem sooner, and how much of an improvement we really did.

G. Ann Campbell wrote:But back to your original question: analyze legacy apps for monitoring while you work to clean it up? Yes, absolutely. If you've been given time to do this kind of work (and talking the business into that without having already shown someone some numbers can be challenging) then I think you'd absolutely want to use SonarQube to identify a) exactly the scope of the problem and b) where to start. And once you've started, why not use SonarQube to give everyone the warm/fuzzies about the progress you're making?

More good advice. Next time, I'll know better.

Thank you, Ann!

Burk
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: SonarQube in Action: Legacy code