Who is your best friend in your programming?

I am constantly surprised because my code has become much better after asking a colleague to look over it. I don't mean a formal review in a meeting room, or posting code publicly on the internet for people to look into, or some kind of troublesome pairing . Simply try to summarize and explain and then give your code to a fellow programmer – that's all there is to do.

This of course is nothing new. A Practical Guide by Karl Wiegers, Peer Reviews in Software: A Practical Guide has been a clear guide to this since 2002.

Bạn nên có một người bạn thân trong lập trình để review code lẫn nhau. You should have a close friend in programming to review each other's code.

I don't think anyone would argue about the value of having someone else look through your lines of code, but there are many cases where people stop it. In the book chapter titled A Little Help From Your Friends (pdf), author Karl explained as follows:

Busy programmers are often reluctant to take the time to consider the work of a colleague. You often have the wrong mentality of underestimating a colleague and asking you to review his code. Does he lack confidence? Does he want you to do what he is thinking? Some people who disagree with reviewing the code are mocking that, "Anyone who needs someone else to review his code should not be paid as a software developer."

In a healthy software engineering culture, team members often connect with each other to improve quality and increase their productivity. They understand that the time they spend on reviewing the work of their colleagues will be offset when other members of the group review their own products. The best software engineers I've ever known are enthusiastic about finding their code reviewers. Indeed, receiving many reviewers throughout their careers has helped them become the best software developers.

In addition to the book chapter above, you can read Chapter 3 (pdf) on Process Impact website. This is not merely a feeling, but there are real data behind it. Many studies have shown that code review is very effective.

The average detection rate of errors is only 25% when using unit testing, 35% if using testing function, and 45% when using integration testing. In contrast, the average performance of design review and code is up to 55% or 60%.

So why don't you review the code? Maybe just because you still haven't found a close friend in programming yourself!

You probably remember when we were in school, people often advised you to get a close friend and connect with them, right? This will help you avoid troubles and become safer. Yes, the same rule should apply when you are building software. Before you check-in the code, give them to your best friend first. Can you explain that? What does that remind you of? Is there anything you miss?

Now I will send you the link of a cartoon.

Review the code in the meeting room. But seriously, this cartoon illustrates exactly what we are looking for. It doesn't need to be too complicated to be effective. WTFs / minute is a perfectly acceptable measurement unit for use with your programming buddy. Extreme Programming (XP) has been promoting pair programming for many years, but I think the buddy system is a very different way of doing but with the same results.

Besides, does anyone don't want to be half of some great coding pair?

The couple programmed close friends. It was a much more exciting way than being tied to the same computer with another person. Think about all the perfect classic couples out there:

Individual individuals can create great things, but two highly motivated colleagues can accomplish even better when they work together. Make sure that at least one coworker is someone you admire or at least be respectful enough to get into your buddy system. (And if not, you might want to consider jumping to another company.)

One of the most interesting points of programming is that you don't have to do it alone. So the question is: Who is your programming buddy ?

ITZone via vinacode

Share the news now