Code with a choke (M. Fowler refactoring)

  • Tutorial
Hello.

A small cheat sheet for beginners, and everyone else who forgot, according to the book Refactoring. Improving existing code Martin Fowler .


What for? When and how?


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

Code with a choke


What you need to get rid of in the process of refactoring and when writing new programs.

  1. Code duplication.
  2. Long method.
  3. Great class.
  4. A long list of options.
  5. Divergent modifications.
    If, when adding new functionality, you have to modify several methods and a significant part of the code in the class.
  6. Shot Shooting.
    If, when adding new functionality, you have to make the same changes in a large number of classes.
  7. Envious features.
    The method is no longer interested in the class in which it is located, but in another.
  8. Data groups.
    Similar groups of data in different parts of the code.
  9. Obsession with elementary types.
  10. Operators of type switch.
    Unforgettable about OOP.
  11. Parallel inheritance hierarchies.
    Duplicated code.
  12. Lazy class.
    Not used or containing few methods (remaining after refactoring / designing).
  13. Theoretical community.
    An excess of abstractions is also harmful.
  14. Temporary field.
    If a class has variables that are used in one of five methods, it is better to pass this variable to the same method through a parameter, and not through a constructor or some other way.
  15. A chain of messages.
    A deep sequence of calls to the necessary information, through objects in the class hierarchy.
  16. Mediator.
    The class delegates most of the methods to another class.
  17. Inappropriate proximity.
    Classes should not expose closed parts, i.e. inner kitchen. When inheriting, subclasses should know the minimum required information about the parent.
  18. Alternative classes with different interfaces.
    Duplication of logic.
  19. Incomplete library class.
    Do not be afraid to expand the functionality of library classes: extension methods or decorate an object of a library class.
  20. Data classes.
    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
    The evidence of a code with a “smell” needs to be refactored. Perhaps the code remains for future refactoring or describes complex manipulations

I do not provide a solution to these problems, since you can take for the base what is described in the book. And taking into account experience, something different.
Read on for a technique: Composing methods .

What a profit.


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

Afterword


I 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 enter the Arena.

Also popular now: