Reconstruction principle,

Reconstruction principle,

Before introducing a new technology, we generally need to talk about its history and main principles. Of course, these things are boring and can easily induce sleep worms. However, it cannot be understood. Fortunately, not too many.

If you already know the definition and principles of refactoring and how to refactor it, Skip this section. All right, the book is going to pass on.

Total returned directory

 

1. What is refactoring)

Depending on the context, refactoring has two definitions:

Reconstruction (TERM): an adjustment to the internal structure of the software. The purpose is to improve the comprehensibility of the software without changing its observability and reduce its modification costs.

Refactoring (verb): uses a series of refactoring techniques to adjust the structure of the software without changing the behavior that the software can observe.

1. The purpose of refactoring is to make the software easier to understand and modify.
2. refactoring does not change the observed behavior of the software-the functionality of the software after reconstruction is as old as ever.

When using refactoring technology to develop software, there are two completely different actions: Add new code and refactor. This is"Two hats".

When adding new features, you should not modify existing code, just add new features. Through testing, you can measure your work progress.
During refactoring, you cannot add new features. You only need to improve the program structure and modify the test only when necessary.

Ii. Why reconstruction (Why)

1. Rebuilding and Improving Software Design

2. refactoring makes the software easier to understand

3. refactoring helps find bugs

4. refactoring improves programming speed

Iii. When to refactor (When)

The author puts forward that, in almost all circumstances, it is opposed to specially allocating time for reconstruction. Refactoring should be performed anytime, anywhere. You should not refactor for refactoring. The reason for refactoring is that you want to do something else, and Refactoring can help you do those things well.

Three rules: Do something for the first time, and do something similar for the second time. Although you will dislike it, you can barely do it. If you do something similar for the third time, you should refactor it.

Let alone three.

1. refactoring when adding features

The most common time is to help me understand the code to be modified when adding new features to the software.

If you find that you need to add a feature for the program, and the code structure makes it difficult for you to achieve your goal, you should first refactor the program to make it easier to add features, then add the feature.

2. Rebuilding when fixing errors

Refactoring is used in the debugging process. To make the code more readable, You can deepen your understanding and identify bugs.

3. refactoring during code review

Refactoring can help me review other people's code, and help the code review to get more specific results.

4. How to tell the manager)

"How can we say something about restructuring to the manager "?

For quality-driven managers:

Using refactoring during review is a good solution. A lot of research shows that technical review is an important way to reduce errors and increase development speed.
Find a review, review, or software development book to find the latest quote, which should allow most managers to understand the value of review.

For "Progress-driven" managers:

The best way is not to tell him. The manager asked me to finish the work as soon as possible. As for how to complete the work, it was my business. I think the fastest way is refactoring, so I will refactor it.

In fact, most refactoring introduces more indirect layers for the program. The indirect layer is a double-edged sword, because every time one thing is divided into two parts, you need to manage one more thing.

The indirect layer also has its own value.

1. Allow logical sharing

For example, a sub-function can be called in two different locations, or a function in the base class can be shared by all sub-classes.

2. Explain the intent and implementation separately.

You can select the name of each class and function, which gives you a chance to explain your intention.

3. Isolate changes.

4. encapsulation condition logic.

V. restructuring challenges

1. Database

• Most commercial applications are closely coupled with the database structure behind them.
• No matter how careful the system hierarchy is, reducing coupling, changing the database structure still forces you to perform a long and tedious data migration.

2. Modify the interface

For published interfaces, you cannot modify the interface safely only by modifying the caller. You must maintain both the new and old interfaces at the same time. Fortunately, this is not difficult. Please try to do this: let the old interface call the new interface. At the same time, mark the old interface with the Obsolete in C.

Do not release interfaces too early. Please modify your code ownership policy to make refactoring smoother.

3. Design changes that are difficult to complete through refactoring

It is difficult for us to reconstruct a system built without considering security requirements into a well-secured system.

When shouldn't reconstruction be made?

1. When you rewrite all the code

Sometimes the code is too messy, and refactoring is not as simple as rewriting.

There is a clear signal in rewriting: the existing code can not run normally at all, and the code is full of errors and cannot run stably.

2. project deadline approaching

Refactoring can indeed increase productivity. If there is not enough time at the end, it means you should have reconstructed it.

Vi. Reconstruction and Design

Reconstruction has a special mission, and it is complementary to design.

Refactoring can bring about a simpler design without losing flexibility. This reduces the difficulty of the design process and reduces the design pressure.

VII. Reconstruction and Performance

There is a frequently asked question about refactoring: How will it affect program performance?

• We do not agree that performance is ignored to improve the purity of design, and it is no way to pin our hopes on faster hardware. Although refactoring may make the software run slower, it makes the performance optimization easier.
• Except for real-time systems, the secret of "Writing quick software" in any case is:First write out the adjustable software, and then adjust it to get enough speed.

VIII. Summary

The first step of refactoring is always to build a reliable test environment for the code to be modified. A good test is the basis of refactoring.

Refactoring technology is to modify the program at a small pace. If you make a mistake, you can easily find it.

Any fool can write code that the computer can understand. Only good programmers can write code that is easy to understand.

The code is read by people first, and then run by computers.

What is the pace of refactoring? It can be expressed in such a loop:

While (refactoring) {test (); small modification ();}

Okay. There are so many theoretical knowledge. To Be Continued...