The benefits of code review don't need me, this mainly discusses code review.
Way problems.
If you have patience, you can jump to the end to see the article I quote, and then come back to see if I have to think.
The earliest concept of contacting code review is just when I have just entered the project group (probably in October 2002), the manager participated in a Microsoft training, came back to give us the benefits of Code Review, and then launched a tariff The motion of the code code review.
..... (not finished) .......
We use code reviews as a method of qualyness assist and team learning
Team Learning
This is the purpose of our code review, everyone should always keep in mind:
For the same question, everyone has their own angle and there is a different understanding. So, by listening to others, learning his understanding of the problem, contributes your own understanding and suggesting to everyone. This way we can improve work efficiency.
Similarly, it is different for programming, each person is not good or familiar, and the code review also provides you with a chance to learn.
Quanlity Assurance: The so-called "authority is fascinated", a person is very easy to get into astray, but others can see the problems at a glance, let you realize.
Finally, according to my understanding, give you some suggestions (what to add or discuss please):
1. Prepare beforehand.
Before the review, the code author provides the code location, and those who participated in the review first familiar with the code according to their actual situation, and there is a problem to record, and discussions when reviewing.
2. The code review "is not the code to the code"
Go back to us to do code review, all discussions do not deviate from "Team Learning" and "QuangLity Assurance". Even if there is a problem with the code being reviewed, everyone discovers and helps correct our purpose.
The code and assessment of the code review will not have any contact.
3. Review afterwards
What feelings, thinking, I have to remember, share with you, don't throw away. You can make a discussion better by your thinking.
.....(to be continued)
http://www.agilemanagement.net/articles/weblog/anti-patterncoderewrites.html
