Practice 5 of agile development "loose programming": code check (large R & D team, learning team, 139 team, mentoring system, code review)

This article is the fifth part of the "loose Pair programming" series. (One, two, three, four, five, six, seven, and eight, the ninth and later articles in this series can be found in the topic catalog .)

The loose pair is different from the tight pair. Two people don't always sit together to locate the problem and solve the problem at any time, but sit together for a short time. There are two main tasks at the post-Checkpoint: one is to check whether the results meet the requirements (what to do), the other is to check whether the code is faulty (how to do it), and the other is to check the code.

Code check (also known as code review code inspection) is a long-standing but mysterious thing. It was initially introduced in software development related to life-related and major property, A typical example is SSOs (the U.S. Aerospace program). Each code segment is reviewed by six people before it can be written into the database. The result was that before 1989 (no data is available since then), SSOs had only one failure in space. The Code review activities I personally participated in include code review for a digital TV CA system (25 programmers only have 1 test, which has been used for CCTV) code review of a telecom billing system (2400 defects found in one week), review of a telecom O & M system (200 important defects found in two days, one of which has plagued the team for five years) the Code review of an aviation lossless Testing System (the customer only fails once within one year after delivery ).

The basic principle of code check is to believe that the human brain (rather than human eyes) is the best tool to judge the quality of Code. For example, if the Code contains a line: if (I = 1001) return die () can hardly be detected by tests, including automated tests, but it is visible to the naked eye.

I wrote a "complex and thorough" code check training material, but later I found it too complicated and not thorough. The following describes an amateur but effective code review method.

-----------------------------------------------------------------------

Programmer's Quality View

Some people once divided programmers into four levels: writing available software (roughly the status of college students) and writing reliable software (roughly the status of some professional programmers ), write exquisite software (breakthroughs in simplicity, maintainability, and reusability) and write deep-thinking software (what the design patterns, MVC, jquery, and early creators of Ole and RPC do ).

But in reality, it is often found that many programmers stay at the first level: "Test it, when detecting the defects, I changed to "This can be run without any change". "This editing is just a hard-to-read point." The Code check between teachers and students is the process of improving programmers from the first level.

The team of 25 programmers and 1 tester mentioned in the first section was our team in and maintained a good quality atmosphere. Especially because you know that no testers have wiped your ass, leaving defects is equivalent to asking you for trouble, so you have to get used to preventing problems before they happen. This product developed very well later, and occupied 60% of the market in (unknown later ).

How to check

"Experts have to develop a lot of code on their own, and it takes a lot of time to check the code for new users ......" This is a common question. The answer is: "Every day, it takes no more than 15 minutes to check the next checkpoint. You can see what you are talking about and stop when the time is up ."

Generally, experts can write more than 100 lines of valid Code (counted by semicolons) every day. There will be more than 200 new users, but not more than (they are charged for writing code ), that is, within 10 screens. Experienced users must know that they can find problems in five seconds after they look at the new software.

There is often a situation where the experts "cannot understand" the code of the novice, of course, not because the technology is too subtle, but the writing is too messy. But it does not exist in the loose Pair programming. As masters and apprentices join each day, these 200 lines of code can be described as dozens of lines. If the code has been checked every day, there should be no more problems.

Check what

This is the focus, including:

1. Structure Problems

The biggest problem with the code is not the technical defect in one or two places, or the business logic error, but the poor Compilation of the entire software. Both can be detected and corrected through test or use, but the latter is different. If you think about all the mess you 've seen, do you feel the same way? Where is the problem? Why can't I change it? The whole software looks messy and cannot be started.

Specific structure problems include: copying code repeatedly (no function encapsulation, no template/generic ......), Function is too long (too long for a screen), error encapsulation (inappropriate public/no interface/no cohesion/strong coupling/encapsulated irrelevant methods in the class ......), Content error (multiple irrelevant classes are placed in one file/improper naming ......) And so on.

Correcting structural problems is an important way to move from writing reliable software to writing exquisite software.

(I have written several articles on "code simplicity" in my blog for your reference)

2. Business logic problems

Is whether the software meets the requirements. Masters and apprentices often have different understandings of business needs. They can take this opportunity to synchronize and introduce Po (product managers/planners...) when necessary ......).

Some people will say that the business logic problem is not just a test? However, a test usually takes a long time and some logic tests require certain trigger conditions. In addition, the test only finds failure (not as expected) and does not discover defects (defect, where is the problem?), no one can find the cause after the accumulation is long.

3. Programming literacy problems

A lot of problems come from the state of "doing the same thing as doing the same thing", such as naming/initial value/indentation/line breaking ...... However, the best practices are always better than new users.

For example, bool result = true; this statement has a problem. If it is just initialized, it will be declared successful first, and there will be hidden risks. This is a real case, and there is also a branch that returns this true by mistake (the actual case is an hresult ). This issue is not a test but a code check. In fact, the test can hardly find these problems. For example, the above Code will incorrectly return this true when a file cannot be opened, and in the test, it will hardly destroy the file to test the results.

In actual use, you don't need to pull a list too long. Just tell the apprentice what the master can think.

The apprentice does not need to learn the day, as long as he can learn the teacher so well. I used some checklists when I was doing cmme Consulting, AND THE PROMOTION ended with failure. The tables are for the consideration of top-level security software. using them in common projects is a disaster.

Several Questions

1. Will the master be tired after checking every day?

Incomplete check is to discover defects, but to improve growth. If repeated problems are always found, this cannot be taught. A studious apprentice has been close to the master for half a year. Considering that the master is generally two years longer than the apprentice, we allow a person to speed up 1.5 years.

2. Will it not starve to death, master?

Yes, no. If the Master stops, even if he does not teach others, he will be surpassed sooner or later. The master also needs to learn. The fact is that masters who teach apprentices can learn, but those who will learn can teach apprentices.

3. Who will the master learn?

Mentoring system is the underlying team system (1 master + 1 ~ (About 3 apprentices), there is a larger structure and a higher master. We have previously set the personnel level to be guided (apprentice)/can be guided (also apprentice)/can provide guidance (master) /trainable (the highest level of experts in the Team). At the last level, you need to share the content with you on a regular basis.

As a senior technician, the master also has the opportunity to go out for training and purchase books.

It is also important for masters to learn independently, and experience cannot be replaced. You must treat your experiences and others' experiences as experiences.

4. I have made great contributions to the preparation of my software. Why should I help my apprentice?

The software is a series system, and the entire software crashes (the Web software is better) in one link ). Therefore, software quality depends on the worst part, not the best part.

Code review does take time to make the best part worse, but it makes the worst part much better, thus improving the overall quality.

------------------------------------------------------------

At the work level, the code check ensures that the quality of the Code, especially the structure quality, can be achieved by the master, thus ensuring the success of the project.

From the perspective of learning, code check allows the apprentice to learn continuously/progressively, which is far lower than the master's time cost to reach a higher level.

Mentality is the key. The apprentice cannot feel that there is a back-end to let the teacher discover the problems, cherish the time of the master, and use the time of the master to learn different content each time; the Master cannot feel that the apprentice has learned to be a threat to himself, and the threat is always present. Not from his disciples, but also from others' disciples. He can only improve himself.

At this point, the content on all practical aspects has been basically completed. The next article will mention some issues related to "139 teams". The so-called "139 teams" is a large team that uses loosely paired programming.

 

Click to download the free agile development textbook: Martian agile development manual