Shulou(Shulou.com)06/03 Report--

Introduction:

In agile software development, the speed of code generation is much higher than that of traditional Waterfall. Because we've got a tighter schedule. So with so much code, how can you ensure the quality of the code? Many people may think directly of static code detection tools. Yes, it is possible to define a code review rule to ensure the quality of the code, but that is only from a language point of view, so is the logic optimized? Has reusability been optimized to the extreme? These are things that static code tools can't do, so we need Code Review

Implementation method:

For those who have been on the project team for a long time:

Although the traditional code review is to checkout the code from the warehouse and look at it, for large projects, that kind of code review has no effect, because you see the code as well as the code, just like what you see in the sea, except water is heaven, and you will soon lose your way. The experience of our team is generally to use the crucible tool for code review, which I have introduced in my previous blog: http://supercharles888.blog.51cto.com/609344/1229660

Because our code submission produces a uuid every time, and we submit more on a sub-function basis, we also create events in crucible on a submission basis, so we can clearly know how effective the implementation of a specific function is.

The specific process is as follows:

We also use the traditional peer review code, because it is difficult to see the problem by looking at our own code, but it is easy to see the problem by looking at other people's code critically, so we code review in pairs, the front-end people review each other, and the back-end people review each other.

For those who are new to the project team:

People who have just come to the project team, because they are not familiar with the business logic, it does not make any sense to ask him to review the code directly. The most important thing is to be familiar with the code so that they can start the project quickly. At this time, I do not advocate that they use code review tools, but sign all the code directly. My experience is: start the server in debug mode. Then in the key line on the breakpoint (back-end code breakpoint), and then in the front-end you use Firefox to open, open FireBug, in the key js file corresponding line also hit the breakpoint (front-end code breakpoint), and then completely step by step way, step by step, at the same time the value of watch key variables change, although it is very slow, but you will be very familiar with the logic of the code and impressed. And for a project, although there is a lot of code, there are not many key processes (to judge whether these processes will finally do Regression, if you want to do Regression, then even key processes), if you grasp the key processes, it is tantamount to grasping the principal contradiction. This is the best habit of getting started with projects. According to the experience of our team, generally at a senior engineer level, we can start the project in 2-3 days and start to take over the task.

Summary:

(1) for the elderly of the project team, the code review tool is used to code review, so that the implementation of the code can be reviewed from the perspective of functional modules.

(2) for the members of the new project team, the step-by-step strategy of debugging mode only grasps the core process, so as to grasp the core process of the project as quickly as possible.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.