The art of revising the code

This book mentions a concept I have not been aware of: Legacy code. The so-called legacy code, refers to the passage of time, the previous code, even if perfect, it is inevitable that the corruption, loss of the original convenience and appear rotten smelly or do not write test code, or the legacy code has many precautions, but its production is inevitable. How to solve it is the core of the whole book.

The first part of the book describes the mechanism of code modification, including perception, separation, and the use of seams and tools, as well as a brief description of legacy code and the importance of testing. It can be said that reversing legacy code is inseparable from testing.

The Legacy Code modification algorithm consists of the following steps:

(1) Determine the point of change; (premise: Understanding Code)

(2) identify the test point; (Prerequisite: Clearing the link between the code)

(3) Solution dependency; (solution dependency is the prerequisite for writing unit tests for a class)

(4) Writing tests; (writing feature tests that conform to the current behavior of the code)

(5) Modification and reconstruction. (fix bugs, improve design, etc.) if there is a test overlay

Reasonable testing is necessary, so the technology of solution dependence is the most important of this book. This is why the book uses a large number of chapters in the back to describe the reason for the solution dependency.

Later the pseudo-class can also be said to be a part of the test, in order to test the convenience of the design.

The middle part is not difficult to understand, and there are not many complicated concepts. He puts forward many practical and simple questions that are encountered in modifying the code, such as the lack of time and the long and far-flung revision process. It can be said that after the analysis of the theory, it is not the problem of the code processing that we begin to consider the problems that may be encountered in the actual situation. What's more, it's a technical help, not a theory.

The last part of the article is about the materialized implementation of the solution-dependent technology. For example, the solution-dependent technology that is dependent on the class's internal:

Subclass and Override methods: rewrite the few internal interfaces that are not tested, and test the interfaces of the original classes by instantiating the overridden derived classes. The rewrite here refers to the implementation of the virtual function, not the overwrite.

Extract and rewrite the call: encapsulates the API and overrides the interface

Extract and Rewrite factory methods: Used to instantiate pseudo-objects, avoid changing interfaces, essentially replacing instance variables.

Extract and override get method: Defer get instance variable for C + +. Because C + + is forbidden in the constructor of the virtual function mechanism, it is no longer possible to call the subclass rewrite factory method in the constructor function.

Solution-dependent technologies in specific situations:

Decomposing a Method object: Reconstructing a giant method

Naive parameters: Avoid parameter dependencies

Encapsulate Global References:

Replace global references with the Get method: Facilitates overriding the Fetch method.

Definition completion: the definition and implementation of C/s + + is separate, replacing the original behavior by overriding the implementation.

Connection substitution: Use link-time seams, replace libraries, DLLs, and so on to implement behavior substitution.

Exposing static methods: Avoid instantiation of objects for objects that are difficult to instantiate.

The change function is a function pointer: used for C's behavior substitution, not recommended.

Overall, the beginning of the whole book focuses on the establishment and analysis of the theory, then the two chapters are to carry out specific discussion and application of the theory, to explain to us the legacy code and processing methods.

The art of revising the code