"Refactoring, improving the design of existing code" reading notes

Refactoring, is definitely one of the most important things in the process of writing a program. Before writing the program we can not understand all the requirements beforehand, the design will certainly have a poorly considered place, and as the project needs change, it is possible that the original design has been changed beyond recognition. What's more, we seldom have the opportunity to complete a project from start to finish, basically to take over someone else's code, even if the project is from scratch, it is possible to inherit the code of the other team members. We all have this experience, see other people's code feel like excrement, there is a strong desire to rewrite the impulse, but must suppress this impulse, you completely rewrite, may be better than the original, but a waste of time not to say, it is possible to introduce the original non-existent bug, and, you are not necessarily better than the original design, Perhaps the original design takes into account some of the things you have not considered. We write the code, will someday be taken over by others, it is likely that others will have the same impulse as we are now. So, what we're going to do is refactor, start with a small-scale refactoring.

Refactoring not only improves the existing design, it also helps us to understand the processes that are difficult to understand. For example, a complex conditional expression, we may need a long time to understand the role of the expression, but also may see a long time finally understand, after not long and forget, and now also to look at the beginning, if we use the expression Extract method abstract out, and an easy to understand the name, If the function name is good, the next time we see this code, we don't have to look at the logic to see what this function does. If we do a proper refactoring of all the hard-to-understand parts of this function, we can abstract each small logic into a small function and make a very easy-to-understand name, and when we look at the code it's possible to look at it like a comment, without ever guessing what the code is doing by looking at the implementation of the Code as before. A good code is better than a comment, after all, the comment may not be updated in time.

"Refactoring, improve the design of existing code," This is a classic, I believe many people have heard or read, read this book will find that the book is a lot of simple things, and many things are what we usually do, but the author summed them up. Rename field, for example, is an easy-to-understand name for hard-to-understand fields, which we have done, but more often, we are blind to this field, such as the abbreviation for the field "IP", which has taken a long time to understand the code, and finally found to be "INPUT ”。 The result of reading this book is that refactoring melts into the entire code process, so refactoring is no longer a separate task, but a function that is not easy to understand, refactor, and to add new features when it is written in the process of writing code.

This book is written in Java, and the Java version is very old.

Some things in the book are too absolute, such as to see Switch refactoring, but this is not realistic, such as Android Development, menu onoptionsitemselected, this is certainly not refactoring, for many control Onclicklistener, It is also common to set up a listener and differentiate convenience points by Viewid, especially in adapter GetView, where a onclicklistener for each control generates too many objects. Of course, this is not to say that the refactoring method is ineffective, but that this approach reminds us that when we see this situation, we need to consider carefully whether the current situation needs to be reconstructed, if it is not necessary, it would be good.

But there are some things that are noteworthy, such as the encapsulation set (encapsulate Collection), when the caller requests a collection object of a class, we'd better not return the collection object, but instead return a non-modifiable copy of the set to the image, and add/ The function that removes the data. For example, for Android-developed adapter, we often add methods that return data collections and set data sets for the convenience of adapter, but it is not safe to determine what the caller will do when the collection is obtained. If the caller modifies the contents of this collection, we know nothing about it, and in Android, if the caller gets a adapter list of data and modifies it in a non-UI thread, it will be problematic.

Before refactoring, check if you have a reliable test mechanism. These tests must have the ability to self-test, after all, refactoring can destroy something, we have to rely on testing to help us find these problems, do not because the test can not capture all the bugs do not write tests, because the test does catch most of the bugs. However, to be ashamed, I seldom write tests, especially Android projects.

There are a lot of simple tricks in the book, and I'm sure we've all used most of the refactoring techniques, just unaware. This book is just a summary of it and makes us aware of refactoring this skill and letting refactoring into our entire writing process, so refactoring is everywhere.

Some of the refactoring techniques in the book, in my sense may not be a refactoring technique, such as to add parameters to the function, if the parameters are not enough and must be added, we will certainly add, this is functional modification or refactoring, casually how to understand it, but as a note, or all these are recorded.

There are only three notes to this book, is a simple record of all the refactoring techniques in the book, convenient for later review, as for the specific operation steps or examples, later want to see the book on the line, or can be found on the Internet. The following link is a C # version of the refactoring series, but not the C # version of the book, where the techniques are mostly the same, Templar: 31-day refactoring series.

Refactoring list:

List of points:

Code bad taste:

Author: angeldevil
Source: Www.cnblogs.com/angeldevil

Welcome to my personal site: angeldevil.me