How does a lone developer code review?

Question

I've had an epic google on this topic and also looked long and hard through the suggested answers to this quandary so please I just want some concrete advice if such exists. Here's my situation. I work as the sole developer at a very small company, my boss used to hack a bit of classic ASP but no longer uses and thus has lost most of his technical skills.

We're looking into tightening up our coding and deployment practices and code review seems like a must. The only problem is that a traditional code review process is absolutely impossible under the circumstances. So what kind of mitigating processes might one try out to go through code before one presses the commit button on source control which don't require a review session with peers.

Personally I'm so far coming up empty but I guess this is time to innovate so go nuts.

Answer 1

Maybe it's obvious, but I always look hard at the diff before committing and ensure each modification does what I thought it did when I wrote it.

Answer 2

If you have skilled friends you can trust you might want to bounce your ideas off them, to make sure you are not doing anything foolish architecturally.

I find heavy unit testing is helpful too.

Answer 3

I asked about code review communities and got some good answers, such as:

• http://www.refactormycode.com

Answer 4

It's hard, but at least, you could wait for a few hours, so your mind may rest, and be able to think a little bit more objective.

So, you may end your day, go to sleep and the next day perform your own code review, trying to spot weak points. Probably with the sleep hours, you mind may criticize your self better.

Answer 5

You're missing a crucial aspect of code review: another coder.

Seems like a good way to get around this would be to find a way to look at your code with "fresh eyes." Set up a schedule to revisit code you've "completed" and look at it again to see if you can (a) understand what you did and (b) improve on it.

This admittedly takes discipline (that I get only occasionally) but without someone else to catch things you've missed I don't see any other way around it short of posting things here that you suspect might need attention.

Answer 6

Do you have a continuous integration environment and build-time quality checking tools?

I'd suggest give your circumstances that code reviewing would be more of a problem than a benefit.

CI + Code quality automation and decent test coverage may be a much better alternative.

Answer 7

This seems like the perfect opportunity to use Test Driven Development. Done correctly, this will tend to make you look at the process of creating code from both sides; the result and the routine.

Answer 8

It's true that it's less than ideal to review your own code, but I've found that code that I wrote just a few weeks ago is almost as foreign to me as code written by other team members.

The facts that (a) I don't always remember the exact reasons I wrote code the way I did and (b) I am constantly learning, so (I hope) I am a better coder now than I was a while ago, both give me the ability to look at my own code critically.

If you've been working on the code for a non-trivial amount of time, a self-review of your code should be almost as effective as a peer-review.

Answer 9

By not describing your development environment, it looks like you want someone to describe a code review at a high level.

I find that after code has been written and as a part of "white-box-testing", I run my code through a debugger to follow the logic.

Unfortunately, more than one set of eyes is needed for a good code review. So, go through your logic on paper first as one set of eyes. Wait a while (overnight?), then go through the code again in a debugger as another set of eyes.

Hopefully your language of choice provides a good code coverage tool of some kind.

Answer 10

You could always still code review with your boss. It will be slow, since you'll have to do more explaining to him, but I find that the act of trying to explain code to someone who has no clue what it's doing forces me to look at it from a perspective other than mine.

Getting a forced fresh perspective can really help.

Answer 11

Been there done that many times. Here is one thing to do : find a good, competent development shop in the area and pay them the [INSERT HOURLY FEE] to take the code and review it.

Another trick is to minimize the need for reviews by using lots of team oriented tools. Especially TDD and continuous integration. The automated testing and building really enforce discipline.