Introduction:
In agile software development, from the point of view of the code generation rate, much higher than the traditional Waterfall generate speed. Because we have a more compact arrangement of the time. Well so much code, how to ensure code quality? Many people may think of direct static code testing tools. Yes, that is the definition of a code inspection rules to ensure the quality of the code, but that is just from the language point of view, the logic is already the most optimized? Whether reusability may have been optimized to the extreme? These are static code tools can not be done, so we need to Code Review
Method to realize:
For the project team has been in a long time for people who:
While traditional code review is to checkout the code from the repository, and then look down, but for large projects, such as code review has no effect, because you see that in addition to the code or the code, just like you see in the ocean in addition to the water that day, it will soon be disoriented. Our team's experience, is generally used crucible tools for code review , I used to blog this tool has been introduced: http://supercharles888.blog.51cto.com/609344/1229660
Because every time we submit the code to generate a uuid, and we are submitting more sub-function as a unit, so we crucible also create an event to submit to the unit, can be very clearly know that for a specific function, its implementation of how it works.
Specific process is as follows:
We also used the codes of traditional peer review, because the code is difficult to see to see their own problems, but look at the code with a critical eye it is easy to see the problem, so we are twinning code review, the tip of each person review, the rear end of another human review.
For the people who first came to the team:
Who first came to the project team, because the business logic is not familiar with, so he went directly to submit for review the code as a unit is no sense, they are the most important thing is familiar with the code so that the project can get started quickly, this time, I they do not advocate code review tool, but rather directly to sign the code of all the whole, my experience is: the server is started with debug mode, and then marked with a breakpoint (back-end code breakpoints) at a critical line, and then in the front end you use Firefox open, open FireBug, key js file in the appropriate line is also marked with a breakpoint (front-end code breakpoints), then go completely in a single step of the way, came step by step, and watch the value change of the key variables, so go again although very slow, but the logical flow of the code you will be very familiar and impressive. And a project, although a lot of code, but not many critical processes (to determine whether these processes is based on the last to do Regression, if to do Regression, then even if the key processes), if grasp the key processes, is equivalent to seize The main contradiction. This is the best way to get projects habits. According to our experience team, usually a senior engineer level, 2-3 days to get started and start the project next task done.
to sum up:
(1) The project team for the elderly, with the code review tool code review, so that the functional module can be achieved from the perspective of code review
(2) For the new members of the project team, the use debug mode single-step strategy, only to seize the core processes to the project as quickly grasp the core processes.
This article comes from " parallel lines cohesion " blog, http://supercharles888.blog.51cto.com/609344/1262016
Reproduced in: https: //www.cnblogs.com/JoannaQ/p/3251413.html