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 the Remaining 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 without ‘and’.