"Refactoring to improve the design of existing code" reading notes and experience

"Refactoring to improve the design of existing code" reading notes and Experience first chapter reconstructs the first step of refactoring a case, establishing a reliable set of test environments for the code that is about to be modified. Processes and methods have a secondary impact on the outcome of the project, and the primary impact is people

Without a reliable test environment, do not refactor the code, then the problem is:
- What is a reliable test environment. in the fourth chapter, when the answer is reconstructed, the amplitude of each modification is small, which makes it easy to test and find errors.

This is the book throughout the history of a refactoring experience, every day to reconstruct a little, each change a little, the pace of change must be small, modified after the compilation test. Any fool can write the code that can be in the computer, only to write the code that human easy to understand is a good programmer

The code is first to read, and the second is to let the computer run.
So the first thing is to write easy-to-understand code, and then consider the performance factors. The rhythm of the reconstruction

Test, small change, test, small change, test

How to refactor quickly and safely

while (refactoring) {
    test ();
    Minor modification ();
}

Chapter II Reconstruction Principles

This chapter focuses on the concept of refactoring.

Depending on the context, there are two definitions of refactoring

1. Noun form definition: An adjustment to the internal structure of software, in order to improve its understanding and reduce its modification cost without changing the observable behavior of software.

2. Verb form definition: Use a series of reconstruction techniques, without changing the software observable behavior premise, adjust its structure.

The focus here is "without changing the observable behavior of the software", and should not add new functionality and modify the code errors found when refactoring. It is easy to introduce new bugs in both functional maintenance and code maintenance.

Personally, it is easy to modify the function errors found when refactoring.

When this happens, the author suggests that:
When refactoring, there are new ideas and new errors, which are recorded next to each other and re-organized for functional maintenance.
This is likened to "two hats": Adding new features and refactoring

When adding new features, you should not modify the existing code, just add new features. By testing, you can measure the progress of your work.
Refactoring you can no longer add new features, just improve the program structure, only if absolutely necessary to modify the test. Why

1. Refactoring to improve software design
2. Refactoring is software easier to understand
3. Refactoring to help find bugs
4. Refactoring to increase programming speed

Personally, the benefits of refactoring must be realized after refactoring to find a large piece of code (about 10 classes), 1.1-point refactoring. Finish it, experience it, do it again, experience it, and the benefits of refactoring, love is hard to open. when

The author opposes the allocation of special time for refactoring, which itself is not an opinion should be allocated time to do things, refactoring should be carried out anytime and anywhere, should not be reconstructed for reconstruction.

Three times rule: charm, three reconstruction

Do something for the first time, do the same thing for the second time, although it will be offensive but can be reluctantly done; the third time you do something similar, you should refactor.

Three points of time that can be refactored:

Refactoring when new features are added.
When adding new features to the software, refactoring helps me understand the code that needs to be modified

refactoring when patching errors.
refactoring during debugging to make the code more readable, deepen understanding, and find bugs.

Refactoring when reviewing code.
Refactoring helps me review other people's Code. "Pair programming" in extreme programming, the enthusiasm of code review to play to the extreme. How

"What to say to the manager about refactoring"

For "quality-driven" managers:

It is a good idea to use refactoring during the review process.
Find a book about review, review, or software development to find out the latest citations, which should allow most managers to recognize the value of the review

For a "progress-driven" manager:

My advice is: Don't tell him. The manager asked me to finish as soon as I could, and that was my business. I think the quickest way is refactoring, so I'll refactor ^-^ difficult

Refactoring is limited and cannot be reconstructed blindly.

Database refactoring The vast majority of commercial programs are tightly coupled to the database structure behind them, regardless of how carefully the system is layered, reduced coupling, changes in the database structure, or a lengthy and tedious data migration effort (migration)

Interface refactoring

For an already published interface (published interface), it is not possible to modify the interface simply by modifying the caller. You have to maintain both the old and the new interfaces, fortunately, it's not hard to get the old interface to call the new interface. Also, use the Java-provided deprecation or the obsolete in C # to mark the old interface.

Difficult to reconstruct design changes
Refactoring is an improvement, if it is wrong from the root, or the

When not to refactor existing code is too confusing, refactoring is better than rewriting

It is difficult to make such a decision, and there is no good standard to judge when refactoring should be abandoned.
Rewrite has a clear signal that the existing code can not run properly, the code is full of errors, unable to run stably.

Remember, the pre-refactoring code must be able to run the project Pro in most cases
If the project is nearing the deadline, you should avoid refactoring. Other

Refactoring and Design

Refactoring shoulders a special mission, which complements the design. Software is more malleable and entirely thought-out than a machine. With refactoring, you can still pre-design, but not necessarily find the right solution, as the understanding of the problem deepens, the solution will change, refactoring makes the cost of future changes is not high.
Refactoring can lead to simpler designs without compromising flexibility, reducing the difficulty of the design process and reducing the pressure on the design

Refactoring and performance

How refactoring will affect the performance of the program.

First, the author does not agree: In order to improve the purity of design and neglect performance. While refactoring may make software run slower, it also makes software performance optimizations easier. In addition to real-time systems, the secret of "writing fast software" in any other case is:

first write the adjustable software, then adjust it to get enough speed.

Three ways to write fast software:

1. Time-Budget law
2. Continuing attention to law
3. Performance Improvement method

An interesting thing: when you analyze most programs, you'll find that it consumes a fraction of the code for most of the time. Equal optimization code, 90% of the optimization effort is white, because most of your optimized code is seldom executed

So optimizing performance requires a measurement tool to monitor the running of the program and find out where the program is consuming time and space. Then focus on these performance hotspots.

To be Continued ...