"The way of the programmer's cultivation"--the approach of practical effect in chapter II (i)

Vii. Risks of repetition
We feel that the only way to reliably develop software and make our development easier to understand and maintain is to follow the principles we call dry:

Every knowledge in the system must have a single, unambiguous, authoritative representation.

　　　　Dry-don ' t Repeat yourself.

Don't repeat yourself.

A different approach is to express the same thing in two or more places. If you change one of them, you have to remember to change the rest of the place. Or, just like the special-shaped computers, your program will be forced into submission for self-contradiction. This is not a question you can remember, but a question of when you forget.

　

　　How does repetition happen?

Most of the repetitions we see can be categorized into the following categories:

• forced repetition (imposed duplication). Developers feel they have no choice – the environment seems to require repetition
• unintentional repetition (inadvertent duplication). Developers are unaware that they are repeating the message.
• non-patient repetition (inpatient duplication). Developers are lazy, they repeat, because that seems more difficult.
• the duplication between developers (Interdeveloper duplication). Several people from the same team (or different teams) repeated the same message.

　　Imposition of repetition

Sometimes, repetition seems to be imposed on us. Project standards may require documents that contain duplicate information or duplicate information in the code. Multiple target platforms each require their own programming language, library, and development environment, which allows us to repeat common definitions and processes. The programming language itself requires the structure of some repetitive information. We all work in situations where we feel powerless to avoid repetition. There are, however, ways to keep a piece of knowledge in one place to comply with the dry principle and make our life easier.

　　multiple representations of the information . At the coding level, we often need to represent the same information in different forms. We may be writing server applications that use different languages on the client and server side, and need to represent a common structure at both ends. We may need a class whose properties are mirroring the schema (model, schema) of a database table. You may be describing a book that includes a program fragment that you are compiling and testing.

With a little ingenuity, you can usually eliminate the need for repetition. Often the answer is to write a simple filter or code generator. You can use a simple code generator each time you build your software to construct structures in multiple languages based on common metadata representations. Class definitions can be generated automatically based on the online database schema, or the metadata that was originally used to build the schema.

　　the document in the code . Programmers are taught to add comments to the code, and good code has many comments. Unfortunately, no one teaches them why the code needs to be commented, and the bad code needs a lot of comments.

The dry law tells us to put low-level knowledge in code, where it belongs, and leave annotations to other high-level instructions. Otherwise, we are repeating the knowledge, and every change means changing the code and changing the annotations. Comments will inevitably become obsolete, and untrusted annotations are no worse than comments at all.

　　documentation and code . You write the document, and then you write the code. Some things change, you revise the document, update the code. Both the document and the Code contain a representation of the same knowledge. And we all know that in the most stressful times-deadlines are approaching and the most important customers are shouting-we tend to postpone documentation updates.

　　language Issues . Many languages impose considerable repetition in the source code. This is often the case if the language separates the interface of the module from the implementation. C and C + + have header files in which the names and information of the exported variables, functions, and (C + +) classes are repeated. Object Pascel even repeats this information in the same file. If you use a remote procedure call or CORBA, you will repeat the interface information between the interface specification and the code that implements it.

　　

　　Unintentional repetition.

Sometimes, repeating errors from the design.

Let's look at a sample from the distribution industry. Suppose our analysis reveals that a truck has models, license plates, drivers, and other properties. Similarly, the properties of the shipping route include routes, trucks, and drivers. Based on this understanding, we have written some classes.

But what happens if Sally calls in sick and we have to change the driver? Truck and Deliverroute all include drivers. Which one do we change? Obviously, this repetition is bad. Normalize it according to the underlying business model-is the attribute set of the truck's bottom really supposed to include the driver? Where's the line? Or maybe we need a third object to combine drivers, trucks and routes. No matter what the final solution is, we should avoid this kind of nonstandard data.

When we have multiple interdependent data elements, there is a less obvious non-canonical data. Let's look at a class that represents a segment:

1 class line{2      Public : 3 Point      start; 4 Point      end; 5      Double length; 6 };

At first glance, this class is always reasonable. The segment obviously has a start and end point and always has a length (even if it is 0). But there is repetition here. The length is determined by the starting and ending points: change one, and the length will change. It is best to make the length a calculated field:

class line{    public: Point     start;     Point end;      double Length () {return  start.distanceto (end);}};

In the future development process, you can choose to violate the dry principle for performance reasons. This often happens when you need to cache data to avoid duplication of expensive operations. The trick is to make the impact localized. The violation of the dry principle is not exposed to the outside world: only methods in the class need to be aware of "good behavior".

classLine {Private:     BOOLchanged; Doublelength;     Point start;    Point end;  Public:     voidSetstart (point P) {start = p; changed =true;} voidSetEnd (point P) {end = P; changed =true;} Point Getstart (void)    {returnstart;} Point Getend (void)    {returnend;} DoubleGetLength () {if(changed) {length=Start.distanceto (end); Changed=false; }        returnlength; }};

This example also illustrates an important issue with object-oriented languages such as Java and C + +. Where possible, you should always read and write the properties of an object with an accessor (accessor) function. This makes it easier to add features such as caching in the future.

　　Non-patient repetition

　　Every project has time pressure-it can drive the best people in our midst to take the power of short cuts. Need a routine similar to what you've written about a routine? You will be tempted to copy the original code and make some changes. Need a value that represents the maximum number of points? If I change the header file, the whole project will have to be rebuilt. Maybe I should use a direct number here, here, and here, need a class similar to a class in Java runtime? The source is there (you have permission to use), so why not copy it and make the changes you need?

If you feel tempted, think of the old adage: "Haste makes waste." You may be able to save a few seconds now, but you may lose a few hours later. 、

Non-patient repetition is a repetitive form of easy detection and treatment, but it requires you to be trained and willing to spend some time in advance to avoid future pain.

　　The duplication between developers

On the other hand, it is perhaps the most difficult to detect and deal with repeated occurrences between different developers of the project. The entire feature set can inadvertently be duplicated, and these repetitions may not be discovered for years, leading to various maintenance problems.

At the top level, this issue can be addressed through clear design, strong technical project leadership, and a well-understood division of responsibilities in the design. However, at the module level, the problem is more subtle. Common functions and data that cannot be zoned into an obvious area of responsibility may be implemented many times.

We feel that the best way to deal with this problem is to encourage the developers to communicate with each other actively. Set up a forum to discuss common issues. Let a team member act as a project information manager whose job is to facilitate the exchange of knowledge. Specifies a central area in the source tree for storing practical routines and scripts. Be sure to read other people's source code and documentation, whether it's informal, or do a review. You are not spying-you are learning from them. And remember, the reciprocal of the visit--Don't be bothered by others delving into your code

　　

　Make Reuse Easy

All you have to do is create an environment where it's easier to find and reuse what you already have than to write it yourself. If it is not easy, we will not reuse it. And if you do not reuse, you will have the risk of duplicating knowledge.

"The way of the programmer's cultivation"--the approach of practical effect in chapter II (i)