Friday, February 27, 2009

Code Reviews – Why Do Them?

I’ll start off my code review series on why you should do code reviews.  I’ve doubted myself on why I should write this entry.  After giving it some more thought, I found out that many college students do not conduct code reviews while in school.  Most industry hires will have done code reviews.  If you have been an independent developer, you probably have not done them.  So this post is geared towards those who have not done them.

Code reviews are a great way to find out everything from nitpicks to design changes to security flaws that may exist in your code.  When I started as an intern, I had not completed any code reviews in college.  When I did my first code review with Office, I found out quickly just how little I knew about my coding.  It was like a wake-up call.  Almost all code reviews coming back to me have some great feedback, either with a security issue, styling, design, performance, etc.  Or even something I never realized about the code (could be that I’m working in new code).  The experienced developers will say that I should have sought out the advice from other developers before making the change.  While that is true, I’m still learning and getting better at that.  That is something for all junior developers to keep in mind: seek out the advice and help of those more senior to you.

You learn from other developers; many times developers more senior (not in age, necessarily) than you.  For the majority of them, they are senior for a reason.  They know their stuff and want to make sure that you understand the issue fully before trying to implement or fix it.  You should actively seek out their knowledge on the subject and be willing to accept their criticism and feedback about what you have done.

When you are in college or doing your own coding with no thoughts about a code review, you tend to have a different mindset when you develop.  Think about that for a minute.  You tend to think differently when you know others will be reviewing your code.  That’s an important take-away.  You have pride as a developer.  Most of us do.  So we want to make sure that we show that pride to other people.  I do… and I am sure you do as well.  If you are coding independently, you may cut some corners, not be as efficient, leave an Easter egg behind, etc.  These, and more, will be called out in code reviews.

There are a couple of different levels of code reviewing:

  • Grammar, spelling, variable names, syntax, comments, spacing, and argument checking
  • Design issues and security flaws

With code reviews, you should definitely think about how all the different components (not just different classes, but methods in the same class) use the code and ensure they will not be broken or affected.

To wrap this up, I do have advice for professors: students need to be performing code reviews while in classes.  They should start in their introductory computer science class.  Students need to learn quickly that fellow colleagues will be reviewing their code in the industry.  Students can definitely be critical of other students, so they should be taught good code review practices.  Technical writing courses should focus on ways to structure their comments to not offend the submitter.  I’ll have more to say on code reviews in more posts.


Thursday, February 19, 2009

Another blog? UGH!

Yes, this is YAB, yet another blog.  I’ve wanted to get back into writing, share my thoughts with others about my experience in the tech industry, and create an avenue for discussion of topics that interest me.

My goal (like many other bloggers) is to create a post once a week.  However, it may come down to about once every two weeks.  Regardless, I do have some thoughts on the first couple of posts in mind.

If you are interested in why “enOZero”, many of my colleagues and coworkers call me Oz.  It’s from my last name.  I would like to thank the staff of the Microsoft Intern Game for giving it to me and the other Andy who forced the group to come up with a nickname for me.  That’s the Oz part.  The other part is one and zero, just one flipped around so that I could use OZ for the middle.  As for the pronunciation of enOZero, it is “e-no-zero”.

In the mean time, sit back and relax… If you have any ideas for blog posts, please feel free to post a comment.  I will do my best to read every comment that appears.