With the past few days I have been reading and analyzing jCodeCollectors source code. Frankly it isn’t very good, a fact which Alessandro would readily admit and did on his Github readme.

Using Google Code Pro, it’s clear there is a lot of dead code. From just reading the comments and translating them using Google Translate a lot of them are extremely redundant. There is a lot of pointing out the obvious, commenting for the sake of commenting and not enough about why certain decisions were made. Comments are about the why, not the what.

I haven’t drawn up or used any software to derive the design of the overall application; from what I can gleam from the code base, there is none. Just lots of singletons, massively nested code sections and God objects.

Lots of the work is done on the GUI, which isn’t that bad in the current application design, on a standard desktop it’s very quick, too quick to be an issue. Realistically I would like there to be a lot less of these kind of blocking operations.

Other issues with the code base are:

• Lack of proper logging.
• Not internationalized.
• No unit tests.
• Plenty of corner cases probably not covered.
• Database is not abstract enough, not easy to swap in a new one.

The type of plan I would propose at this point is, putting a good suite of tests in place, a job which I have started by using Code Pro to generate a fair whack of them yesterday. Because I intend on making a final token release of this software for people who may or may not still be using it I intend on just making some subtle refactors to the code base and cleaning up some ugly behavior on the front end. A more longer term plan would be the refactor the code into a more client/server architecture and perhaps move towards a more web-based approach. At the very minimum I would like to experiment with JavaFX for the frontend. Sorry mac peeps, this apps going to end up looking very different.