DEV Community

Discussion on: How do you know when to NOT refactor?

Collapse
 
ahferroin7 profile image
Austin S. Hemmelgarn • Edited

I usually run thorough this quick checklist:

  1. The code is in production (that is, it's either past beta, or it's in active use on production infrastructure).
  2. There are no existing bugs that would be solved by refactoring the code.
  3. There are no new features that would be significantly simpler to implement following a refactor.
  4. The code meets all required coding standards for the project.
  5. There are no security-related anti-patterns present in the code.
  6. You are not the primary maintainer of the code in question.
  7. The code cannot be refactored without changing the API exposed to other components of the software.

General logic based on this:

  • If points 1-5 are all true, don't refactor.
  • If any of points 2, 3, or 5 are false for multiple reasons (for example, multiple bugs would be fixed or multiple features would be easier to implement), count them as false once for each reason they are false.
  • If at least one of points 2-5 are false, and both points 6 and 7 are false, refactor.
  • If point 4 is overwhelmingly false for the whole project, consider re-writing the coding standards before you think about refactoring.
  • If point 1 is false, ignore point 7.
  • If three or more of points 2-5 are false, consider ignoring point 7.
  • If point 6 is true and you would refactor, propose the refactor to the primary maintainer of the code in question.
Collapse
 
coreyja profile image
Corey Alexander

This is an amazing checklist! I'm gonna save this for later!

Collapse
 
crenshaw_dev profile image
Michael Crenshaw

This is great, thank you!