Peter Sergeant recently wrote an article about code reviews. He had a lot of really interesting points and ideas about code reviews, like using a review tool, and scheduling review time regularly. I've never really used a review tool, but I use ReSharper's ToDo Explorer to keep track of notes, review areas, and code smells. I like the idea of a regular review, but in some teams (especially where I work today), I highly doubt it would work.
I believe code reviews are an invaluable tool that have in your SDLC. I believe this because it does many different things. Code reviews help improve code quality coming from all developers, it helps enforce domain level knowledge among developers, and allows for communication among developers to be opened up.
As a junior developer, I initially thought as code reviews as a way to improve my code quality. I was easily intimidated, and insecure in what I was producing. I stuck with it, and after the second review or so, I learned that wasn't the case. There is a sense of "You don't know what you're doing," at times, but you can't have that attitude. I believe everything is done for a reason, and that every developer chose a specific solution for a reason.
Code reviews allow developers to ask questions, and learn new things. For example, if I had a question how to write an automated unit test a specific area, I could put a note in there asking for help. "Is this sufficient for testing?" is a review note I frequently had. By finding those areas, and having a conversation about them you're producing better quality code, and then you're going to be able to build on top of that quality to ask better questions such as "Can we use a row test to increase the efficiency of these test?" Further more, when I looked into more experienced developers' code, I see new methods and patterns I've never seen or used before. I can then ask questions about them. If these patterns are easy to make sense, the senior developer will easily be able to explain his logic. If he can't then there probably needs to be some refactoring.
Domain level knowledge is very difficult to obtain. On all of my major projects, they've been on subjects that I know nothing about. I've always talked to the users to get information I needed. But as I became more exposed to that project and product, I was able to contribute that knowledge to newer developers. As an example, I may say "This is unnecessary for us to write because we've never allowed users to input strings into this field." That is communicating business rules and experience into each others' code base.
Finally, it forces communication about architecture among developers. I see a lot of code duplication in my project I currently work on. I found nearly the same functionality in 7 different spots. And when there was a bug, I had to go in and fix it in 7 different spots. The question of "Can we tear that out and put it in one spot?" was asked. However, I asked the question of, "Why is it this way in the first place?" There's always a reason - even if it is laziness. Unfortunately, it took me 3 attempts to find all 7 spots. So it looked like I had a ton of bugs come back. Had we had a code review on the development on one of these areas, perhaps we may have said "Keep it DRY", and go forward. Maybe the developer didn't know about the other six spots with that functionality? Perhaps it can go into a class with other similar functionality that another developer is working on?
So code reviews are valuable for a number of reasons, to anyone of any skill level. I've only listed some of the reasons here, but it is interesting to think about. I'd like to hear stories and reasons for others' stances on code reviews.
No comments:
Post a Comment