Refactoring is a powerful Agile technique for improving existing software. Having Java source code that is understandable helps ensure a system is maintainable and extensible
Pasted from <http://www.methodsandtools.com/archive/archive.php?id=4>
Who needs refactoring?
Software starts on a small scale, and most of it well-designed. Over time, software size and complexity increases, with that bugs creep in, and thus code reliability decreases. Software developers, particularly when they are not the original authors, are finding it increasingly difficult to maintain the code, and even harder to extend. The code base, which in any software company should be a valuable asset, at some point may become a liability.
What is needed to prevent the software from ageing prematurely? Strategically, attention of management and software developers is the most important factor. On the practical side, application of sound development methods will slow this ageing down. However refactoring can reverse this ageing when applied properly, preferably with good software tools that aid in the detection, analysis, and characterisation of the problems, and ultimately allow fixing them.
What exactly is refactoring?
Refactoring simply means “improving the design of existing code without changing its observable behaviour”.
When should one consider refactoring?
Ideally, refactoring would be part of a continuing quality improvement process. In other words, refactoring would be seamlessly interwoven with other day-to-day activities of every software developer.
Often, however, schedule pressures do not permit to implement a clean solution right away. A feature may have to be added in a hurry, a bug patched rather than fixed. In these cases, the code in question should be marked with a FIXME /TODO note
Refactoring adds to the value of any program that has at least one of the following shortcomings:
- Programs that are hard to read are hard to modify.
- Programs that have duplicate logic are hard to modify
- Programs that require additional behaviour that requires you to change running code are hard to modify.
- Programs with complex conditional logic are hard to modify.
A refactoring operation proceeds roughly in the following phases:
Questions to ask, actions to take
Detect a problem
Is there a problem? What is the problem?
Characterise the problem
Why is it necessary to change something? What are the benefits? Are there any risks?
Design a solution
What should be the “goal state” of the code? Which code transformation(s) will move the code towards the desired state?
Modify the code
Steps that will carry out the code transformation(s) that leave the code functioning the same way as it did before.
- Move Class
- Extract Method
- Extract Superclass
- Replace Conditional with Polymorphism
- Simple, direct, prose散文
- Literate 精通文学的
- Care ( clean code always looks like it was written by someone who cared)
- Small, Expressive, simple
- Readable, maintainable and extendable code
- Meaningful names
- A class name should be a verb
- Method should have verb or verb phrase names
- Avoid using the same word for two purposes
- Functions should do one thing only
- Function should be small
- Function arguments (The ideal number of argument for a func is zero)
- Don’t repeat yourself
- Don’t comment bad code, rewrite it
- Each blank line is a visual cure that identifies a new and separate concept
- Vertical density implies close association
- Variables should be declared as close to their usage as possible
- Instance variables should be declared at the top of the class
- Dependent functions
- If one function calls another, they should be vertically close, and the caller should be above the called
- Every programmer has his own favorite formating rules, but if he works in a team, then the team rules
- Objects and Data Structures
- Objects hide their data behind abstractions and expose functions that operate on that data
- Data structure expose their data and have no meaningful functions
- Error handling
- Prefer exceptions to returning error code
- Don’t return null
- Unit Tests
- Test code is just as important as production code
- Readability makes a clean code
- One assert per test
- FIRST (Fast, Independent, Repeatable, Self-validating, Timely)