This looks interesting. When we introduced PMD we did it with a major, swathing tech debt phase that took about 1 week to cover a code base of ~10^6 LOC. It was painful, and a step taken so that we could turn on PMD as of part of our CI flow. Going back, I wish we'd taken a more incremental approach as we lost a lot of time doing it (1000 dev hours or so?).
This is an approach I would gladly explore if we did another project that was introducing PMD midstream - I like it much better. One of the biggest difficulties was having people address PMD problems who didn't have a great deal of insight into the code they were fixing, and so it did cause another round of "repair" to code that was inadvertently broken on a functional level. This looks to help avoid that by associating PMD issues with a dev closer to the code.
Incremental approach only works if the code was not that bad to begin with (properly modular, mostly SOLID, no need for major rework) and when you have unit tests.
Plus it is folly to attempt rework while writing features based on the old, broken code.
I agree. We were lucky (not smart, I'd say, just lucky) in the sense that we turned on PMD as a CI portion prior to a lot of major code being written. To share one experience of my own, I wrote an entire application - not a major one, probably < 2000 LOC altogether - right when we were midstream.
I began by ignoring PMD's presence (it wasn't blocking my work at the time) and merrily went about writing the code. Right when I was nearly finished the application, PMD went live and I ended up realizing - with PMDs help, code review, input from more experienced devs in the domain - that my code was shit - poorly structured, not very testable, not following great design principles - and as a result I re-wrote the entire thing. It wasn't time-costly but it was an eye-opening lesson - getting some things right off the bat is important and saves a lot of headache later.
If we'd had more code like mine in place at the time PMD went live we'd have spent an order of magnitude more time re-writing so many things, in many cases nearly from the ground up.
Even the initial effort caused a lot of wailing and gnashing of teeth, but in truth it did help us learn and improve more quickly than if we'd kept left to our own devices.
Great to see that you are using diff2html (https://diff2html.xyz). I built it for Codacy trying to create a better diff experience when reviewing code. Also you can get PMD, Checkstyle as part of code reviews and pull requests @ Codacy.com and it is free for open source for ever.
He recommends git blame to identify which files should be prioritized when improving the codebase, but git log and a bit of shell-fu can make remove the need for manual browsing.
For example, obtaining the list of the 10 most modified files is as easy as:
This is only a simple example but something non much different could be used to get a better indication of actual activity, limit the search to specific timeframes or users, etc...
I recommend using SonarQube instead of just PMD to prioritize technical debt. SonarQube includes PMD rules as well as multiple other sets of static analysis rules. And it has reports to help identify and prioritize problem areas.
This is an approach I would gladly explore if we did another project that was introducing PMD midstream - I like it much better. One of the biggest difficulties was having people address PMD problems who didn't have a great deal of insight into the code they were fixing, and so it did cause another round of "repair" to code that was inadvertently broken on a functional level. This looks to help avoid that by associating PMD issues with a dev closer to the code.