Comment left here – it’s also worth following some of the links in the article.
Never install the Java Decompiler, JAD, and look at the library code you are dependent on.
Just don’t.
If you do, however, never run the FindBugs utility (which I recommend for all lazy code reviewers btw) against the decompiled code.
Just don’t.
Or you will cry.
I’ve picked up lots of code in my time, and the hardest stuff was Java “o-o” code, because everything is buried so deep and bugs very hard to find. Oddly, Ruby is easy to debug once you’ve understood how metaprogramming works and it is an o-o language. But most of the time you just write code to do what you need to do and write tests for that small thing.
UML etc. etc. – guys you are working at the wrong level. UML blah … once you’ve gone past the initial system design it’s another thing to maintain and it wo’t be. Throw it away and make the code base clean. I’m very old fashioned – I tend to start from a clear data model and view the rest as just a layer on top of it. I don’t care about the class model – it’s usually not worth worrying about and a lot of code is procedural code hidden in static classes anyway – be honest, now. This is particularly true if you are using an o-o to relational mapper – that’s where all the complexity is and you have decided that you want the mapper library to do the work. Data matters, the rest is fluff.
I also recommend finding a formatter for the language you are using if you are trying to understand someone else’s code. It’s amazing how many bugs you find when the formatter changes the indentation to reveal what the compiler/interpreter will actually do with the code.
Read Fowler’s refactoring book, even if you are not a Java programmer, it repays close study.
Old fart signing off now.