
PMD meets Git to prioritize technical debt - walkmod
https://blog.walkmod.com/pmd-meets-git-part-i-a3e60004a421#.bc2yadkng
======
jat850
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.

~~~
AstralStorm
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.

~~~
jat850
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.

------
rtfpessoa
Great to see that you are using diff2html
([https://diff2html.xyz](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.

------
drtse4
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:

    
    
        git log --name-only --pretty=format: | sort | uniq -c | sort -nr | head -n 10
    

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...

------
nradov
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.

------
albertmanet
This seems interesting but I cannot run it on my machine.

It seems that the app cannot contact mongo.

After I restart the app I am able to login, but never able to add projects.

Can you help?

------
libruary
hello friends

