重構現有代碼：Refactoring

1.WHY SHOULD WE REFACTOR?

　　1.Refactoring Improves the Design of Software

　　Without refactoring, the internal design—the architecture—of software tends to decay. As people change code to achieve short-term goals, often without a full comprehension of the architecture, the code loses its structure.

　　2.Refactoring Makes Software Easier to Understand

　　The trouble is that when I’m trying to get the program to work, I’m not thinking about that futuredeveloper. It takes a change of rhythm to make the code easier to understand. 

　　Refactoring helps memake my code more readable. Before refactoring, I have code that works but is not ideally structured. A little time spent on refactoring can make the code better communicate its purpose—say more clearly what I want.

　　3.Refactoring Helps Me Find Bugs

　　4.Refactoring Helps Me Program Faster

2.WHEN SHOULD WE REFACTOR?

　　1.Making It Easier to Add a Feature

　　2.Making Code Easier to Understand

　　3.Litter-Pickup Refactoring

　　4.Planned and Opportunistic Refactoring

3.PROBLEMS WITH REFACTORING

　　1.Slowing Down New Features

　　2.Code Ownership

　　3.Branches

4.Bad Smells in Code

　　One thing we won’t try to give you is precise criteria for when a refactoring is overdue. In our experience, no set of metrics rivals informed human intuition. What we will do is give you indications that there is trouble that can be solved by a refactoring.

　　You will have to develop your own sense of how many instance variables or how many lines of code in a method are too many.

　　Use this chapter and the table on the inside back cover as a way to give you inspiration when you’re not sure what refactorings to do. Read the chapter (or skim the table) and try to identify what it is you’re smelling, t

　　hen go to the refactorings we suggest to see whether they will help you. You may not find the exact smell you can detect, but hopefully it should point you in the right direction.

　　1.MYSTERIOUS NAME

　　　　One of the most important parts of clear code is good names, so we put a lot of thought into naming functions, modules, variables, classes, so they clearly communicate what they do and how to use them.

　　 2.DUPLICATED CODE

　　　　If you see the same code structure in more than one place, you can be sure that your program will be better if you find a way to unify them. Duplication means that every time you read these copies,

　　　　you need to read them carefully to see if there’s any difference. If you need to change the duplicated code, you have to find and catch each duplication.

　　3.LONG FUNCTION

　　　　Since the early days of programming, people have realized that the longer a function is, the more difficult it is to understand. 

　　4.LONG PARAMETER LIST

　　　　If you can obtain one parameter by asking another parameter for it, you can use Replace Parameter with Query (324) to remove the second parameter. Rather than pulling lots of data out of an existing data structure,

　　　　you can use Preserve Whole Object (319) to pass the original data structure instead. If several parameters always fit together, combine them with Introduce Parameter Object (140).

　　　　If a parameter is used as a flag to dispatch different behavior, use Remove Flag Argument (314).

　　5.GLOBAL DATA

　　　　The problem with global data is that it can be modified from anywhere in the code base, and there’s no mechanism to discover which bit of code touched it.

　　　　Time and again, this leads to bugs that breed from a form of spooky action from a distance—and it’s very hard to find out where the errant bit of program is.

　　　　The most obvious form of global data is global variables, but we also see this problem with class variables and singletons.