I'm a Systems Reliability and DevOps engineer for Netdata Inc. When not working, I enjoy studying linguistics and history, playing video games, and cooking all kinds of international cuisine.
The code is in production (that is, it's either past beta, or it's in active use on production infrastructure).
There are no existing bugs that would be solved by refactoring the code.
There are no new features that would be significantly simpler to implement following a refactor.
The code meets all required coding standards for the project.
There are no security-related anti-patterns present in the code.
You are not the primary maintainer of the code in question.
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.
I usually run thorough this quick checklist:
General logic based on this:
This is an amazing checklist! I'm gonna save this for later!
This is great, thank you!