Here is the order of importance when evaluating potential refactoring opportunities while reflecting on your code.

  1. Identify Concepts:
    • Consider the Single Responsibility principle of SOLID.
      • Each collection of responsibilities should only have one reason to change.
    • Group responsibilities at the method level.
    • Group responsibilities at the class or concept level.
      • Group related methods into new classes.
      • Ensure to create a related test class and migrate the affected tests.
  2. Name Things Well
    • Apply the Stages of Naming to variables, methods, class and test names
      • Strive for meaningful names and avoid specific names in tests.
  3. Apply OLID of the SOLID Principles
    • Open/Closed Principle
      • Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification.
    • Liskov Substitution Principle
      • Subtypes must be substitutable for their base types.
    • Interface Segregation Principle
      • Clients should not be forced to depend on methods they do not use.
    • Dependency Inversion Principle
      • Abstractions should not depend on details. Details should depend on abstractions.
  4. DRY (Don't Repeat Yourself)
    • Every piece of knowledge should have a single, unambiguous, and authoritative representation in the system.
    • This principle is often misunderstood, with developers creating abstractions for things that appear similar but represent different concepts.
      • Code is only repeated if it represents the same concept. This is true when the same sentence can be used to describe what it represents with out 'and'.