Ghost Code (M. Fowler Refactoring)

Hello.

A small cheat sheet for beginners, and all the others who have forgotten, according to the book Refactoring. Improvement of the existing Martin Fowler code .

What for? When and how?

I don’t really want to go deep here, because it all depends on many factors: knowledge, necessity, time, a specific project, etc. etc.
The main thing that you should not forget and adhere to that everything good is useful in moderation.
')

Tactile code

What should be disposed of in the process of refactoring and when writing new programs.

1. Duplication code.
2. Long method.
3. Great class.
4. Long list of options.
5. Divergent modifications.
   If when adding a new functional it is necessary to modify several methods and a significant part of the code in the class.
   
6. Shooting shot.
   If at addition of a new functional it is necessary to make identical changes to a large number of classes.
   
7. Envious features.
   The method is no longer interested in the class in which it is located, but in others.
   
8. Data groups.
   Similar groups of data in different parts of the code.
9. Obsession with elementary types.
10. Switch type operators.
    Unforgettable about the PLO.
11. Parallel inheritance hierarchies.
    Duplicate code.
12. Lazy class.
    Not used or containing few methods (remaining after refactoring / design).
13. Theoretical generality.
    An abundance of abstractions is also harmful.
14. Temporary field.
    If a class has variables that are used in one method out of five, then it is better to transfer this variable to that method through a parameter, and not through a constructor or in any other way.
15. Message chain
    Deep sequence of calls to the necessary information, through objects on the class hierarchy.
16. Mediator.
    The class delegates most of the methods to another class.
17. Inappropriate intimacy.
    Classes should not expose closed parts, i.e. internal kitchen. When inheriting, subclasses must know the minimum necessary information about the parent.
18. Alternative classes with different interfaces.
    Duplication of logic.
19. Incomplete library class.
    Do not be afraid to extend the functionality of library classes: extension methods or decorate an object of a library class.
20. Classes of data.
    Divide into logical units. Access to change data should be meaningful.
21. Waiver of inheritance.
    If the heir needs only a small part of the information (data, methods) about the parent.
22. Comments
    Evidence of the code with the "smell", you need to refactor. Perhaps the code remains for future refactoring or describes complex manipulations

I do not provide solutions to these problems, because you can take as a basis what is described in the book. And with the experience, something of their own.
Read on, technique: Compilation methods .

What a profit.

Simplicity in support and understanding of the code, as well as in writing tests.

Afterword

I will add that this is only a necessary minimum.
Depending on the complexity of the project and the architecture in it, more heavyweight principles, patterns and methodologies will appear on the Arena.