12 of the series of agile development "loosely connected programming": L-type code structure (one of quality)

Document directory

• Quality of "Chuan" code structure
• Quality in "3" code structure
• The birth of L-type code structure
• L-type code structure management
• Quality of L-type code structure
• Efficiency of L-type code structure
• Quality Problems in L-type code

This article is part 1 of the "loosely connected programming" series. (Loose Pair Programming topic directory)

Is there a management method that can greatly improve product quality without additional test activities? The L-type code structure is one of the candidate solutions.

Source of defects

To reduce defects, we must first find out where the defects come from? In my own experience, about 20% of new users have made more than 50% of defects in the system. If we expand the population to 80% of new users + medium-level people, it is estimated that they can make 95% of the defects, and the remaining 20% of the experts may only make 5% of the defects, or even lower.

This is the case even when the experts take the initiative to undertake the most arduous part of the task. In fact, the defects mainly come from the programming literacy of programmers, which makes it possible for some experts in the team to achieve close to 0 defects in a timely manner, but as long as there are new players, the program is as messy as a bug.

Quality of "Chuan" code structure

If all the players are responsible for one or more functions, and each person keeps communicating with each other from the upper page, the middle business logic, and the bottom layer data access, how will the defects in the code be distributed?

The typical scenario is that the module in charge of the master has no problem from top to bottom, but this cannot prevent other people from frequently having problems in code, soThe quality of the entire product is not very good.

In some teams that lack management, this development mode is common. However, in some agile development teams, people often adopt this method, that is, they "take the initiative" tasks, complete all the analysis, coding, and testing tasks independently, and then submit the tasks.

Quality in "3" code structure

What if all the team members develop by layer (generally the display layer view, business logic layer model, data access layer data, MVC mode, and controller layer?

This model has been used by my team for many times,The quality is superior to the "Chuan" code structure with vertical division of labor.. The 23 development + 2 testing team mentioned many times started with the "three" type code structure.

The principle of improving the quality of this model is: if the underlying Code such as the model and data that has been repeatedly accessed is handed over to the master, there will be very few defects in the Code; because the same code is "used repeatedly", one defect is found, and the other defects are modified at the same time, the repair cost of the defect is very low. When new functions are developed in the future, when the code is called again, then you can directly enjoy the effect of close to zero cost and zero defect.

The quality problem of the Three-type code structure mainly lies in the business, that is, even if the module-level defects do not become obvious, the business logic errors often exist and the Code calls each other accurately, however, an incorrect logical result is formed. This is especially evident when many experts are busy designing highly reusable underlying modules, while relatively new users are particularly involved in business development. Two testers of that year were hired to solve the problem of business testing.

Another problem with the Three-type code structure is the requirement for gold plating ". Most of the underlying code is prior to the upper-layer code, so there are often over-design situations. When I made the first underlying database, almost 50% of the functions were not actually used. Although this situation was improved later, it was difficult to predict which functions were useful or useless, the problem of gold plating has always existed. Although the problem of gold plating generally does not cause catastrophic consequences, if the masters spend 50% of their time in gold plating, the waste of productivity is also very serious, and the work efficiency is greatly reduced.

Quality and work efficiency of the L-type code structure the birth of the L-type code structure

In my own experience, L-type code evolved from Chuan code.

I found that if there is a new and old programmer with a division of labor, they can complete their own code independently. Generally, the following phenomena occur:

1. New programmers have fewer functions, while old programmers have more functions.

2. New programmers tend to write code into a large block in different layers. If you need to reuse it yourself, you can copy and paste the code.

3. The old programmer tends to classify the code. Although only the programmer can reuse the code, he will still actively extract classes and functions.

4. although the two do not communicate, the reusable classes of old programmers may cover the vast majority of requirements of new programmers, including the vast majority of data-level code access, and some underlying business logic code model and interface code view.

For example, if a person develops a "product management" module, he or she needs to manage the "product line, product, version, and release" layers, while another person is "department management" in development ", to manage layers such as "company-branch-department-team-group", in addition to the obvious reusable database access code and cache, the tree-structure Business Code can also be reused, the display of their interfaces can even be reused.

If the old programmer has developed these reusable codes, the new programmer can directly use them.

5. Old programmers will not experience much "gold plating.

Why? Because he did not develop the underlying library "fully", he developed the underlying library according to his own needs. Our own data (with no careful measurement) is that in our 11000 lines of code, there are more than 2000 functions (an average of 4.5 rows ), in the impression, the number of useless functions deleted is less than 50, which is far less than the subjective feeling of 50%.

However, there is no need to worry that the functions generated by the old programmer "for their own needs" cannot meet the new needs of new programmers. If the reuse design is good enough, new programmers rarely need to write new functions.

L-type code structure management

However, to make the code really reusable, we need to do a little bit of small-scale management-it is not difficult to implement the loose Pair Programming and the 139 team-level model-including:

1. Whenever a reusable class or function is added to a master, "inform" the team.

In our environment, it is enough to scream.

2. When a newbie wants to use or develop reusable classes or functions, ask experts.

This is very important. New users often have the impulse to actively reuse, but there are many possibilities for re-inventing the wheel.

3. When a novice needs to cause underlying library changes, you can use loose Pair programming.

It is generally a good learning opportunity for new users to view and modify the underlying database. By transferring knowledge, experts can also transfer the maintenance of the underlying database to new users, avoid becoming a new toolkit (this is often the case in three-type code ).

Experts can provide some guidance during the modification. For example, they can describe the original working principle in 10 minutes and recommend where to change it.

New users often want to open these underlying libraries to find out, but I find that this kind of unmotivated learning effect is very poor. We should seize the opportunity for new beginners to need the new underlying code, so that they can learn and take over some of the underlying code.

Quality of L-type code structure

The quality of the L-type code is roughly the same as that of the third-type code. Multiple reuse causes hidden defects.

In fact, the underlying library of L-type code does not even require unit tests, so the quality may be high. Because all defects are discovered by different upper-layer applications, no human testing is required. (This causes other problems)

Efficiency of L-type code structure

Because the experts only develop the underlying code when needed, gold plating is effectively prevented.

The L-type code structure has become a high-quality and efficient programming management method.
Quality Problems in L-type code

Some time ago, we were suddenly troubled by the defects produced by L-type code. Where did these defects come from?

As development is coming to an end, we decided to access some upper-layer functions that were developed earlier but rarely used for some limited tests. The results show that because they are the same underlying layer as new function calls, the underlying layer does not come back to verify whether these old functions can still run after each new function is modified, therefore, many of these functions cannot run or even open pages.

The solution afterwards is automated regression testing. We spent about a week building regression tests for most feature pages. Every time before code is submitted (the underlying code may be modified), we will habitually run it again to confirm that all functions are running properly. If it fails, the modification is made and then submitted.

It should be said that any form of reuse, including the L-type code structure, should be combined with automated regression testing.

I am participating in the csdn blog Star Selection. If you have read and liked this article, please vote:Http://vote.blog.csdn.net/item/blogstar/cheny_com