Project on Github and code reviews

Hello,

I recently (in the last few weeks) released a very small project on Github called SummonMonster. I might work on it more later, but for now it does pretty much what I wanted and I am working on something else bigger, so updating it is not a big priority.

This project is an Erlang. I like to play around with Ruby and Erlang at home but for the last few years, I spent most of my time at work with C#. Needless to say my Erlang and Ruby skills aren’t currently up to par with my C# skills.

That’s why I wanted to have the code reviewed. Code reviews are really great. Learning a new language and it’s conventions is always faster when you can have your work reviewed by a peer.

To do this I used a great site which is currently in beta on the stackexchange network. It’s currently called codereview.stackexchange.com and I suggest you give it a whirl if you are in a similar situation.

Code reviews

Of course, code reviews are better done in person. Since I am on this subject, I will give a few guidelines I personally adhere to for code reviews.

First, code reviews are for everyone. No matter the experience or knowledge of both participants, reviews can always be beneficial. The reviewed person gets a chance to explain his ideas, might find mistakes himself in his code and gives information to the reviewer. Following a review, the reviewer is in a better position to maintain the code in question or answer questions on it when the original author is not available.

All of this suggests that reviews are beneficial even if a person is getting reviewed by someone who is more green. This is a great time for the a new member of the team to learn the standards and conventions used on a particular team or project.

Having everyone submit to code reviews also sends a positive message to new members of a team who might be reluctant to being reviewed. Older members can lead by example.

Secondly, it is always better to review the code at hand rather than the programmer and to question the implementation rather than the person who wrote the code.

Third, how the reviews should be conducted and how/if/when corrections are to be made should be decided in advance.

A policy I like is to have most propositions be optional, especially the ones who would result in a major refactoring. In these cases it might be more efficient to simply correct the reviewed person so that future developments will be free of a certain mistake.

Finally make sure to have a flexible code review policy. A lot of times, check-ins are trivial and do not necessitate a review. Imposing a mandatory review will result in time misspent and a negative view on the review process.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s