We build software together. Team sizes vary a lot but it’s usually not 2 or 3. Team members leave, new members join and in the end of the day codebases are shared among large numbers of different and diverse people from development, testing and deployment.
Code reviewing process is what you take into action every time you make modifications to the code’s itself. Even though you change a single line, before committing the code to repository, a peer reviews it and confirms it can be submitted. Reviews can help to decrease the number of bugs, vulnerable code pieces, misuses of coding standards and etc. In an environment with no reviewing practices, actual code wont be directly visible to developers before an other member opens file(s) for editing. Without reviews, even though build passes QA tests,
- Readability of the code,
- Compatibility with coding standards,
- Organization of the codebase,
- Documentation inside the code
/* comments */,
will stay as surprises. These may lead to a dirty and badly organized base after a few years of continuous development. Asking a peer before you integrate new code into your product is a better approach since you may most probably have more time to fix, reshape and enhance your code if you take the action earlier. Usually only one other team will have time to review your code. But reviewing should be done with two people. First one should be a master, the one that knows the existing system well and can see the big picture. He can guess the impacts of your certain changes among the codebase. Other peer should be ideally someone who is not very familiar with the code, so you can test how easy to get into your code if you have to assign a bug to a new member, how well it suits with patterns in software development, how simple and obvious your solution is.
Consequently, whatever you are working on is shared among people. Asking for a review is always better than not asking and keep your actual contribution as a secret until it needs to be changed.
Burcu Dogan 
Great words, unfortunately most small teams won’t have enough resources (or will) to follow these guidelines and end up with messy code in short time.
What do you think about “Pair Programming” with respect to Code reviews?
Pair programming seems to be an applicable solution but we are humans, not machines. Most of the developers like to write alone in a personal and silent environment – such as home. I personally couldnt write a single line of code if someone was reviewing me. It’s very uncomfortable. I dont have the scientific facts about the effectiveness of pair programming, but it’s a no-no for me.
Most expert programmers love pair programming. It is a very effective coaching tool. The result code is twice as high quality as the code you would write alone. But I agree it is not suitable for everyone. A good programmer should be open to criticism and should not take critics personally. What the pairs try to achieve is the best quality code possible and they will both be succesfull if they achieve that. There is no “I” in a team.!
What is your view on TDD?
Development should be test driven. The more you automate the release pipeline, the faster you develop. In cases where small teams develop small scale products for a very limited time span, this is often avoided. Most of the industry (small scale companies) cannot afford to write their own continuous integration tools and scripts. This is still an unsolved issue in the small scale.
@Burcu: Actually, TDD is slower almost always. Microsoft has done a bunch of research into the matter and you can read all their cool findings here: http://bit.ly/163eOW
The upside however is that it’s also almost always better quality.
-A
kuzushi, I tend to believe there is no “fast” software development but fast adoption to changes in specs. No one believes but I’ve seen people who thinks agile is coding where you dont have to leave documentation in code, such as commenting. In fact, agile is the most systematic way of software development, automating the whole release cycle and be able to determine what is being affected as fast as possible.
Hola,
QA tests are not ignorable but unfortunately there are so many websites there are built on one’s hand. It causes code to be unreadable, not extensible and not even stable. But i think TDD is really important on development and also QA testing. If you wanna do agile development, you need to have something watch your back =) Or be ready for the sleepless nights =)
BTW, @Burcu, i want to congratulate you for this blog and sharing.