Disclaimer: I’m aware of the questions How do I review my own code? and What advantages do continuous integration tools offer on a solo project?. I do feel that this question aims at a different set of answers though, as it is about a specific software, and not about general musings about the use of this or that practice or tech stack.
I’m a solo programmer for an Eclipse RCP-based project. To be able to control myself and the quality of my software, I’m in the process of setting up a CSI stack. In this, I follow the Eclipse Common Build Infrastructure guidelines, with the exception that I will use Jenkins rather than Hudson. Sticking to these guidelines will hopefully help me in getting used to the Eclipse way of doing things, and I hope to be able to contribute some code to Eclipse in the future.
However, CBI includes Gerrit, a code review software. While I think it’s really helpful for teams, and I will employ it as soon as the team grows to at least two developers, I’m wondering how I could use it while I’m still solo.
Question: Is there a use case for Gerrit that takes into account solo developers?
Notes: I can imagine reviewing code myself after a certain amount of time to gain a little distance to it. This does complicate the workflow though, as code will only be built once it’s been passed through code review. This might prove to be a “trap” as I might be tempted to quickly push bad code through Gerrit just to get it built. I’m very interested in hearing how other solo devs have made use of Gerrit.
For a single person I would consider Gerrit (which is awesome in bigger teams) to be unnecessary busywork. Yes, you could plug the verification by Jenkins into Gerrit to avoid merging broken code, but you should in principle be able to do to with Jenkins alone.
As long as Jenkins builds all your branches and runs the tests for them you should be fine by just checking it manually before merging. I personally use git-builder to do this and am happy with it.
The advantage of a code review is to have another developer (preferably someone else familiar with the goals of the project) look at your work to find things that you missed. Working alone, you don’t have anyone who can do that, so tools like Gerrit don’t really add value.
However, it might be possible to incorporate additional tooling into your build process to help you find potential problems sooner. Consider some kind of precommit hooks to do things like code formatting against some style rules, static analysis tools like Google CodePro Analytix, FindBugs, and PMD (FindBugs and PMD can be integrated into Jenkins and Hudson), and JUnit test cases. If you’re diligent in the quality of your unit and integration tests and pay attention to warnings generated by static analysis tools, you might find some of the issues that another developer might find in a code review.