File: n459.com/file/25127180-479070079
The following are irrelevant:
-------------------------------------------Dividing line----- ----------------------------------------
What refactoring is, what it is used for, how to do it, what, why, how, and this sentence: easy to understand, easy to modify, is the most straightforward explanation of the method of reconstruction. Of course, the book also includes every ordinary refactoring move and method encountered in daily life. There are actually some theories or ideas behind it, such as the single responsibility principle, and several other principles (opening and closing principles, inside The principle of substitution, the principle of interface isolation, the principle of dependency inversion, etc.), these are summarized by the predecessors, follow the principles, so that the written code can be highly cohesive and low-coupling, and the software project can be more robust and maintain better and longer Life cycle.
What kind of code is good code, in fact, this is back to the programming language itself. The development of programming languages, from the ancient machine language (01), to the later assembly language (imperative), to the high-level language, is actually a process from complex to simple, programming language is for people (programmers) to use Yes, only more people can understand and use it better. In terms of performance, machine language and assembly language have the best performance, but they are too difficult to remember and no one can understand, so high-level languages have appeared. The best understanding is naturally human language, but it is too flexible and too unruly, and the computer cannot recognize it. Therefore, it is as close to human language as possible, and the easier to understand is better code. Use a higher level of abstraction to replace the basic control structure, which allows developers to focus on business scenarios without having to worry about complex underlying operations. Improve the code signal-to-noise ratio (simplicity) and minimize uncertainties to make the code extremely concise. From this point of view, pseudo code is the best code, because it does not pay attention to details, pays attention to business, and is easy for people to understand, "I don't care how you achieve it, I want this effect", and there are almost no bugs.
Good code and bad code, perhaps more differences are reflected in some details, such as the naming of methods or variables (methods are called functions in this book), such as some very subtle habits, etc., these small The combination of these has produced some qualitative changes. The analogy is like building a building. A good-quality building can be seen from every brick and tile.
The language of this book is very plain, not entangled in reasoning, theory, or narrating code history, but through some very homely examples, combined with techniques, moisturizing things to explain the essence of reconstruction silently, the focus is The chapter is worth reading many times, combined with some design patterns, there will be a deeper understanding.
Of course, there are some shortcomings. For example, the examples are written in js, and some features are applicable to Js, which is not easy to understand. Some translations are a bit heavy and not local enough. They are a little hard to read and the translations are not reliable enough.
Chapter 1 Refactoring, the first example,
through an example, let people have a perceptual understanding of refactoring. The examples used most of the refactoring techniques in this book, such as refining functions, inlining variables, moving functions, and using Polymorphism replaces conditional expressions and so on. After reading it, I have a basic understanding of reconstruction. Wow, it turns out that this is reconstruction, and I can do it too. The technique used in it may be used in my daily life. A certain method is used frequently, or infrequently, or it is occasionally used. For example, when refining a function, when it is tortured by copying and pasting a section of the same repetitive code (usually it requires multiple modifications), the code will be encapsulated, placed at the bottom of the class, and decorated with a private Method, so that this class can also be used elsewhere. Furthermore, cross-class and cross-module are also used. What to do? Put it in logic and become a public method, so that other modules can also be used. To sum up, it is the passive use of reconstruction, or irregular use. There is no universal or active promotion to use.
There is also a deep impression, which is to refactor, modify, and iterate in small steps. The example in the first chapter sometimes feels cumbersome. Every time I move such a line of code, it looks like a person is very verbose. However, this is precisely the book or the author’s good intentions. This is also the essence of reconstruction. On the one hand, reconstruction must be like building blocks from the foundation. Reconstruction without side effects, small steps and quick running styles. Reconstruction must be used frequently. The naming is unreasonable. The code is difficult to understand, so it's time to refactor. On the other hand, the method of moving a line of code every time, in fact, the most important thing is to straighten out the thinking and understand the logic of the code, which is also an essence of refactoring.
I remember a training when I first started. The first step is to understand the requirements, then decompose the tasks, set the acceptance criteria, etc. One sentence is remembered for a long time, programmers must not assign a task, immediately write code, but Decompose, straighten out ideas, build work items, decompose tasks, and then happy code.
Chapter 2 Principles
of Refactoring Chapter 1 already has a basic understanding of refactoring. What is refactoring is the little bit of movement and modification. It is plain and seemingly inefficient. Simple, in fact, there are many theories behind it. Refactoring is not done with code cleanliness, but has real benefits. Just like a person, you must maintain some good habits (such as reading, fitness, planning, running, etc.). These good habits will unknowingly affect you and make you successful (sounds very poisonous). So in the field of programming, we must maintain some good habits, principles, thinking, and even thoughts. These will affect you and make you a good coder. Refactoring or refactoring these methods is to distinguish good coders. And the bad code farmer.
What is refactoring? Two hats. Refactoring is both a noun and a verb. For example, to refactor a certain module, which refactoring techniques are used. Generally speaking, refactoring can be regarded as a thinking of programmers, combined with the bad smell of the code in Chapter 3, when you are going to make a method or a module, you must take the refactoring thinking to code and foresee Where may you need to refactor, etc., what bad smells to avoid.
Why reconstruction, there is no silver bullet, think of "The Myth of Man-Moon", reconstruction itself is not done overnight, nor is it a single technique or technique, but a series of combinations, and the reconstruction may also feel that such a reconstruction is good at some time. At another time, you may think that the other is better, such as function refinement, inline variables, etc., and may be converted to each other. The benefits of refactoring are obvious. Hello and me. If it is a one-person project, you can better understand it yourself (often we write code by ourselves, after a few months or days, it will be confused and we need to clarify our thinking. ), if it is a team project, it is easier for others to understand.
When to refactor, the old saying is good, there are repeated and repeated, I think this sentence is too true for me, every time I do refactoring, I feel that I can’t duplicate the code and make multiple changes. Code, long pain is not as good as short pain, and then refined and encapsulated. Preliminary refactoring is about turning refactoring into a habit. Every time you write code, you have to carry this idea and thinking.
How to tell the manager, this is also a contradiction, about it conflicts with the efficiency theory, after all, refactoring is to do some addition and subtraction on the old code, and there is basically no output in the short term. It is better to fix a few bugs. , No value or value is often overlooked. In fact, refactoring often eliminates some potential bugs. Of course, the most important benefit is that a software project is a project, and refactoring is a quality supervisor, which can make the quality better and more robust.
Chapter 3 Bad Smell of Code
A project will rot and deteriorate, or is it because the code has a bad smell, which accumulates bit by bit, causing the project to be overwhelmed and have to be overwhelmed and rebuilt. The bad smell of the code is probably similar to the "ancestral code" that programmers ridiculed themselves. The ancestral code can't be moved. You can only read it yourself, and others don’t dare to change it. Regarding comments, what this book is saying is that good code should not have comments, because the granularity is fine enough and abstract enough, the code itself is explanatory. You can see the intention, group, etc. through naming and context. Before looking at another This book says that good projects should be commented or documented. I can’t wait for every line of code to be commented, which is going to the other extreme. Different people have different opinions.
The bad smell of code chapter, from the common unreasonable naming to unreasonable methods, logic, etc., as long as it is difficult to understand, it is actually caused by unreasonable code. Good code should be close to human language or human thinking, so that people can smoothly read and understand what the code does and how it does it. In a sense, readability is the difference between good code and bad code. Because readability is sometimes one of the important indicators to measure how good the code is, readability ultimately determines the maintainability of the code, even if the only reader of the code is ourselves. We often try to read the code written by ourselves a long time ago, it may be stunned, or spend a lot of time to reproduce to sort out our ideas, based on what considerations, etc., what special cases are used for, let alone make others People come to read and modify our code. When a problem occurs, it is of course a more brief and readable code, which is better to troubleshoot the problem.
When I read this chapter, I am really ashamed to see it, because a lot of unreasonable codes often appear in development, such as too long functions, too large classes, too complicated loops, nesting of if...else, etc. , I once did a method, because it needs to judge various states, after writing about 500 lines of code, whenever there is a bug debugging, it always crashes, and it is impossible to start. The fundamental reason for the bad smell of the code lies in the fact that we did not think about it when developing this function, did not plan the business logic, and then started coding in a hurry, which led to the proliferation of branches and complicated logic, and we had to use many if...else judgments, nesting, and loop Wait to make up. Therefore, you must think before writing the code, analyze the logic first, organize the business, draw diagrams, flowcharts, etc. if necessary, and after the conclusion, if there is no problem with the logic, the next step is to write the code.
Chapter 6 The first group of refactorings
From this chapter, they are some of the most commonly used and more essential refactoring techniques. At the beginning, they felt very ordinary. Many of them are the kind of shifting one line of code and then shifting one line. Code, some techniques still have corresponding inverse techniques, such as inline function-refined function, his eldest uncle and his second uncle are his uncles, taking a step back is equivalent to not taking that. The rare thing is that the author can guide step by step and demonstrate tirelessly. This chapter is worth repeating many times to read to understand, make notes and cheat sheets, and make a habit of writing it down, and take the initiative to do it usually. Many reconstruction techniques seem simple, but the ideas behind them or deeper theories are worth thinking about. All refactoring techniques serve the point of "easy to understand and easy to modify". Refactoring is a step-by-step approach to smaller-grained code, in line with the single responsibility principle.
Refining functions, the first step in refactoring, to avoid the nemesis of too long functions, first analyze the business logic, then separate different business modules, distinguish what to do, usually write code to develop a good habit of writing very small functions, Usually there are only a few lines, more than six lines give off a bad smell.
Reverse reconstruction, inline functions, how to master and refine the degree of function, can not be reconstructed for the sake of reconstruction, over-refactoring, otherwise it will become a bunch of call chains.
Refine variables and refine certain values into meaningful variables. One advantage of this is that you can debug (you often use it, and then delete this variable after you use it). Another advantage is to distinguish state values and understand what the logic is for , Especially useful in conditional expressions such as if, a bunch of conditions and or, usually make people look big, refining variables is equivalent to refining logic.
Reverse reconstruction, inline variables, here to distinguish the relationship between useful variables and redundant variables, if the state value itself is not many, or the logic is not complex, it is easy to understand, without complex calculations, and Or merge, etc., then there is no need for additional variables. Additional variables are also a cause of too long functions.
Changing the function declaration is actually a function renaming. Similarly, there are variable renaming. A meaningful and logically clear naming is very important. Believe that everyone sees var aaa = something must be broken, obfuscated naming is probably part of the ancestral code. A good naming is the foundation. How to do it and what to do can reflect the business logic and make it clear and unambiguous. Naming carefully, a good name may have to be modified many times.
Combining functions into classes and combining functions into changes is about merging similar and similar business logic, which is actually object-oriented encapsulation.
In the splitting phase, contrary to the combination of functions into classes, the essence is to straighten out the business logic and split different logics into one function independently.
Chapter 7: Encapsulation,
Encapsulation, Encapsulation, Encapsulation, Record (data), Encapsulation Fields. The last chapter was a small mess. If you move the statements line by line, this chapter will start a major reconstruction, encapsulation, inheritance, and more. State is the three basic characteristics of object-oriented languages, and some major refactorings in this book basically run through these three characteristics. In fact, which classes and functions are encapsulated, the most important thing is to split the logic, put together code blocks with similar logic and similar functions, and then hide the detailed implementation logic (such as a loop, a judgment, etc.), which will improve the realization. At a high level, users don't need to care about the internal implementation, just use it.
What this chapter completely tests is the planning ability, what needs to be encapsulated, how to expose it to the outside, etc., use more refactoring, and become proficient. After refactoring a few times, you will understand how to split business logic, how to split large classes and methods, and then encapsulate them into small and precise classes.
After reading so many encapsulation techniques, such as encapsulation records, encapsulation classes, and encapsulation functions, the summary is that the idea is very important, but the technique is not important. How you refine the function is more important than the code you type faster.
Chapter 8 Moving Features
This chapter starts with the movement of the method of moving the code. How to move, move sentence by sentence, what's the use, put the function-related code together, organize them together, in the process of moving , Is the logical sorting process. Putting the same reference context code together, the next step is to refine logic, encapsulate functions, encapsulate classes, and encapsulate records.
Replace loops with pipes. Pipes are probably a feature of js. In c#, it is probably lambda or linq. What are the advantages of doing this? It is probably the advantage of functional programming. I have written about the use of the ForEach method of List before. ForEach usage of the collection List: Use functional programming instead of process-oriented, the advantage is that it is more concise and higher-level. Regarding functional programming, I have also summarized before. The functional programming ideas in product development are readily available and better. Just use the ready-made one.
Chapter 9 Reorganizing Data Structure
Reorganizing Data Interface This chapter basically restructures data structures such as fields, records, variables, etc. Value objects are changed to reference objects, and reference objects are changed to value objects. It feels like it is only available in js. Because there are scopes, closures and the like. Other variable renaming, etc., have also been discussed in the previous chapters, and I feel that this chapter is not that important.
Chapter 10 Simplified Conditional Logic
This chapter and Chapter 6, Chapter 7, and Chapter 8, feel like chapters that need to be reviewed from time to time, to learn the new through reviewing the past, and there should be gains every time you read it. All reconstruction techniques All need to be kept in mind and used skillfully. This chapter is also very shocking to me. Some mistakes made in development can also be solved one by one. This is the most practical and most effective key to solve the problem. For example, if...else causes too long functions, too large classes, switches, etc., all benefit a lot. The dispute between guardian sentences and single exit and entry has solved the problem of excessive nesting. All in all, this chapter is very instructive in actual work and solves some urgent needs. Compared with encapsulation and mobile Dafa, simplifying conditional logic is a visible benefit, and at least it can solve short-term pain.
Of course, the essence of simplifying conditional logic is to encapsulate and refactor, separate different branches into a function, and perform different logical services. This is the focus of simplification.