Agile Software Development Practice-code Review Process

Introduced:

In agile software development, the speed of code generation is much higher than that of traditional waterfall. Because we have made the time more compact. How can so much code guarantee the quality of the code? Many people may think directly of static code detection tools. Yes, those are the ones that can define a code-checking rule to ensure the quality of the code, but is that just from the language point of view, is the logic optimized? Has reusability been optimized to the extreme? These are static code tools that cannot be completed, so we need code Review

Implementation mode:

For people who have been in the team for a long time:

Although the traditional code review is to checkout the codes out of the warehouse, then look, but for big projects, that kind of code review has no effect, because you see the code and the code, as you can see in the sea, except the water is the sky, will soon lose direction. The experience of our team is generally the use of crucible tools for code review, this tool I have previously blog has been introduced: http://supercharles888.blog.51cto.com/609344/1229660

Because our code submission produces an UUID each time, and we submit more as a child function, we also create events in crucible to commit as units, and we know exactly what the effect is for a particular feature.

Code we also adopted the traditional peer review, because they look at their own code is difficult to see the problem, but with a critical eye to see the code of others is very easy to see the problem, so we pair to carry out the code review, the front-end people review each other, the back end of the people review each other.

For those who have just come to the project team:

People who have just come to the project team, because they are unfamiliar with business logic, it doesn't make any sense to let him go directly to the review code, and the most important thing is to be familiar with the code so that it can get started quickly, and at this point, I don't advocate that they use the Code review tool, but simply sign it all down, My experience is: Start the server in debug mode, then hit the key line on the breakpoint (back-end code breakpoint), and then in front of you with Firefox open, open Firebug, in the key JS file corresponding line also hit the breakpoint (front code breakpoint), and then completely with a single step way, step by step, At the same time watch the value of the key variable, this walk is very slow, but you will be very familiar with the code logic process and impressive. and a project, although a lot of code, but the key process is not much (judging by whether these processes are the last to do regression, if you want to do regression, then even the key process), if the key process is grasped, is tantamount to grasping the main contradiction. This is the best hands-on project habit. According to our team's experience, generally a senior engineer level, 2-3 days to get started with the project and start the task to do.

Summarize:

(1) For the project group of the elderly, using the Code review tool to review code, so you can from the functional module angle to review the implementation

(2) For new members of the project team, the single step with the debug mode strategy, only to seize the core process, so as to grasp the fastest speed project core process.

This article from the "Cohesion of parallel Lines" blog, please be sure to retain this source http://supercharles888.blog.51cto.com/609344/1262016