A while back, I worked on a project where I led a team that included five developers on their first jobs right out of college, two mid-level developers, and one senior developer. I was the development lead and it was part of my mission to get all the “newbies” set off on the right track […]
A while back, I worked on a project where I led a team that included five developers on their first jobs right out of college, two mid-level developers, and one senior developer. I was the development lead and it was part of my mission to get all the “newbies” set off on the right track in their careers.
One of the things I taught them about was code reviews, not only their importance but how to conduct a code review that was useful and painless, as well as effective with easy-to-use results to track what needed fixing, how it needed to be fixed, and by who. One of the important things I wanted to address with them was which tools to use. So I thought I would share that here too.
As a Java developer, my favorite code review tool is the Jupiter-Eclipse plugin from the University of Hawaii (pause to take a moment to dream about the lush tropics and beautiful beaches of Waikiki).
I have used it on several projects over the years and find that it removes the grunt work from code reviews and allows the team to focus on the important task at hand: improving the code.
What I like about it includes:
The user interface is a little bit clunky, so instead of forcing my team to use it, I proposed an experiment to them. We would use Jupiter for one code review and if they liked it we would keep on using it. If not, someone else could suggest a different tool or we could do it the “manual” old fashion way with someone taking notes in a separate file.
Well, in the beginning the team struggled a little bit with the set-up of the first review (installing the plugin was easy, but deciding on categories and rankings took some debate), but they finally settled on a first draft, we picked the first set of classes to review, and we were off to the races. The first review went something like this:
After we went through the whole process, I asked the team “what did you think?” and everyone was very enthusiastic about Jupiter. So for that team, it became a “keeper”.
I would suggest you give Jupiter a try for your next code review. After you try it, I’d love to hear what you think of it. If you don’t like it, please share why. What code review tool would you use instead?
In my previous post, I walked through common scenarios and attempted to present a high-level...
At ng-conf 2018, the Angular team unveiled an astonishing suite of new features to come...