Reading notes-"Big Talk Refactoring"

Overall aerial view
Recently, I read a book called "Big Talk Refactoring", which uses a lot of examples from the practice, from coding, design, organization, architecture, testing, evaluation, response to changes in requirements, and so on, in-depth and multi-angle how we should reconstruct, constructively put forward a highly efficient and feasible refactoring seven steps. After reading this book, practice refactoring no longer jams, and needs change no longer tangled. Comprehensive understanding of the beauty of reconstruction, legacy systems are no longer a nightmare, automated testing could have done so. This book helps programmers to bid farewell to the inferior code into the subtle design, so that the legacy system maintainers gradually improve the original design, guiding the reconstruction practitioners out of the confusion step-firm. At the same time, it also provides good methods and ideas for managers to strengthen the management and supervision of software quality.
The maximum value of this book is two points:
First, let the reader understand how the real professional-level software development is carried out;
Second, let the reader understand that the real refactoring is a step-by-step how to do.
The author, Fan Gang, divides the lengthy and ambiguous software refactoring process into clear and clear seven steps. So that beginners in the face of the actual software refactoring, will not jam.
This book explains the refactoring far beyond the code level, fully penetrates all aspects of software systems and design, from code, functions, classes and objects, up to design patterns, layered architectures, domain models, software testing throughout the process.

We have heard of the terms and concepts, how many understand or completely do not understand the technology and methods, know but not used or completely do not know the tools and software, these before each play each separate scattered, in this book by Tenon into a strong whole. You will understand the role of each of them, where they should be placed, and see the energy they play when they are in place. The mind has never been sober, we understand the previous do not understand, today this blog, small series on the simple introduction of the story of the big Talk refactoring, why the small series will have a kind of the feeling of the West tour? ' (*∩_∩*)

what refactoring?
To understand refactoring, it is first to fully understand the definition of refactoring. Refactoring (refactoring) is to improve the quality and performance of the software by adjusting the program code, making its program design pattern and architecture more reasonable, and improving the expansibility and maintainability of the software.
The definition of refactoring: an adjustment to the internal structure of software, in order to improve its understanding and reduce its modification cost without changing the "observed behavior of software". Refactoring is about improving the design of your code after it's written. Refactoring and adding new features do not conflict, but when developers switch between the two, they cannot be confused.

Refactoring, is a double-edged sword, developers do not use easily. For example, you're working in an industry right now, but someone tells you that another industry is making more money and faster, so you're struggling with it. Do not change the bar, money to earn less, change it, oneself is a novice, not familiar with the industry. This state of mind is actually a developer's attitude towards refactoring, which can be described by the "dilemma".

why refactor?

Because the original program structure can not meet the user's new requirements, the original program has a loophole (bug), the original program is inefficient, performance is not enough to meet user requirements. So it has to be, and it has to be refactored. But refactoring can not be done casually refactoring, refactoring is to be carried out according to a certain principle, the principle of reconstruction: small Steps to run (a small step to modify the mode, each modification a little bit of a test, and then modify a little bit of testing); Two hats (one is to refactor the original code without adding new features, One is to add new features to meet new requirements).

         a software is always created to address a particular need, the era is evolving, and the customer's business is changing. Some of the demand is relatively stable, some demand changes more intense, and some of the demand has disappeared, or converted into other needs. In this case, the software must be changed accordingly.
Considering factors such as cost and time, not all requirements changes are implemented in the software system. But in general, software needs to adapt to changes in order to maintain its vitality.
        This creates a bad phenomenon: the SOFTWARE PRODUCT was originally manufactured and designed to be well architected. But with the development of time and the change of demand, it is necessary to modify the original function and add new function constantly, and some defects need to be changed. In order to make changes, it is unavoidable to violate the original design framework. After a period of time, the software architecture is riddled with flaws. More and more bugs, more and more difficult to maintain, new requirements are increasingly difficult to achieve, the software architecture of the new needs of the gradual loss of support capacity, but become a constraint. Finally, the cost of developing new requirements will outweigh the cost of developing a new software, which is when the life of this software system comes to an end.
Refactoring can minimize this phenomenon. After the development of the system to a certain stage, the use of refactoring, do not change the external functions of the system, only the internal structure of the reorganization. Through the reconstruction, constantly adjust the structure of the system, so that the system for the change of requirements always have a strong ability to adapt. The
refactoring can reduce the coupling of the project, make the project more modular, and benefit the development efficiency and maintenance of the project. To make the main frame of the project prominent, give a clear idea, a sense of clarity, in fact, refactoring is a maintenance of the framework.

The total number, for the program, refactoring is equivalent to doing a large operation, so must be taken seriously. Throughout the refactoring process, it is continuously tested, tested, and re-tested. We need to practice constantly to be able to be handy with the entire refactoring process. So from the two important reconstruction ideas of "small run" and "two hats", then to reconstruct the system six steps: decomposing large functions, splitting large objects, increasing code reuse rate, discovering extension points, reducing dependence, layering, these are all important parts of refactoring. When refactoring, you should discard large layouts and use small designs. This is a very interesting statement, feeling a little inconsistent with our usual normal thinking habits, the sooner we find the more favorable to correct the error. If the layout is too large, the error may be discovered later, which can be more complicated to fix. If the steps go too far in refactoring, the more time you spend on design, the longer the development cycle will be. Because too much consideration, will cause a variety of problems arise. So a small-run approach to refactoring, because each time only to focus on a subset of the functions, so whether from the design or development, testing the point of view, are very advantageous. Because we are using the "small run" way to refactor, even if we make some mistakes in the middle, or very easy to be found, fixed. This has greatly reduced our workload.

When does refactoring happen?
Refactoring is a habit, a programming habit. This habit allows us to quickly change from rookie to Daniel, you can write high-quality, excellent program. The key to the problem is to reduce the cost and risk of modifying the method, and this method is the system reconstruction. The first step out of the reconstruction is a spiritual test for everyone, and even many people are always wandering at the crossroads, but once out, it will be part of your life.
Without refactoring, the original ecological code is no way to reuse, when we find that the code needs to be reused, should not use the past that simple rough copy paste, reasonable use of the reconstruction method, coupled with careful, serious, immediate testing, you can ensure that the correct code, and make the whole system to reuse it rationally. To improve the maintainability of the system, the key is that you have no such consciousness.
Add a new feature front-end refactoring of the original system with two purposes:
A, the software design is always related to the complexity of the software, the original designers in the original requirements are not complex conditions, but with the addition of new features, software complexity is changing, so the original design must be adjusted.
B, in order to improve the maintainability of software and easy to change, add new features should follow the OCP principle. System refactoring is an effective tool for maintaining high-quality legacy systems in our department.

In emergency change tasks, time is money, we have to use the most time and effort to solve the problem, the difference is how to refactor? --Do a complete design, but only the most urgent part of refactoring.

How to Refactor?
The first step: starting with the decomposition of large functions as business logic becomes more and more complex, programmers always add new code to the original program structure. The original clear and simple program, with the new code constantly added, therefore, most software enterprise legacy systems, the super-large function becomes a common problem. So the first step in refactoring is to start with the decomposition of large functions. Therefore, seeking a systematic point of entry, summing up the large functions of the Division of Logic, the operation of reconstruction "extraction method" function decomposition into a number of different logic functions, so as to optimize the original system structure, improve the reading convenience.
The second step: Split large objects, decomposition of large functions, stranded is the decomposition of hundreds of thousands of methods or functions, followed by the decomposition of large objects. Using the refactoring "Decimation class" to integrate the decomposed functions or methods into the object, while guaranteeing a single responsibility principle, an object or class that accomplishes a business logic responsibility. Finally, the class is merged.
The third step: to improve the code reuse rate decomposition of large functions, splitting large objects, system reconfiguration from disorderly garbled to orderly orderly, the logical flow of the system is also clear, the next thing to do is to optimize the code, follow the "DRY" principle, there is duplicate logic code in the same object, the use of "refactoring method" extracted as the corresponding logical name function; Different objects in the village. Repeat the logical code, and use "extract class" to extract the repeating part as a common class for other classes to invoke. When the repeating class has a side-by-side relationship, use extract parent to extract the same code into a common parent class.
The fourth step: the Discovery Program extensible point system can deal with the changing needs of the business, improve the system's easy to change, is also one of the purpose of the reconstruction system. The system should ensure that the general principle: Predictive Scalable design try not to do too much; "Two hats" design mode-one is the system reconstruction, one is to face the new requirements to realize the function. Following the "OCP principle (open-close principle)" is also the premise of the extensibility point.
The fifth step: reducing the dependence of the program depends on the system is the most fundamental way to reconstruct the system. To reduce the connection degree between functional logic, the new requirement establishes independent function logic, satisfies the coupling degree of the system function, and achieves the low coupling high cohesion of the system development.
The sixth step: layered hierarchical structure is the system architecture designed in the early stage of system development, the default architecture is three layer architecture: Data layer, business logic layer, application layer. The meaning of stratification lies in the logical relationship of independent functions, and improves the system code quality in the face of the change of business requirements, to change the minimum cost of the original logic.

The seventh step: domain-driven design: According to the principle of responsibility for the domain division of the system to form a domain model. The original program structure and the current program structure is very different, not abandon the original system structure, just through the "small run" 1.1 points of evolution, again to ensure the quality level of code and reading, maintenance, change. This is the complete process of refactoring.

Small Series of words: The blog, small part of the simple introduction of "Big Talk Refactoring", blog from the overall control of the whole book, how to reconstruct, why to reconstruct, when to reconstruct, how to reconstruct five aspects of the summary, the focus of reconstruction is not how to reconstruct, but to reconstruct the aesthetic manifestation of the process of interpretation.

Reading notes-"Big Talk Refactoring"