Refactoring and the Art of Improvement

https://medium.com/young-coder/refactoring-and-the-art-of-improvement-19735563fbc2

Here are some common suggestions that sound reasonable, but set different thresholds:

• Refactor when the cost of refactoring is less than the cost of not refactoring. (Sounds good, but how can you make that calculation?)
• Refactor before adding new features if it will make it easier to add those features.
• Ignore ugly code once. But refactor if you stumble over the same pain point twice.
• Refactor opportunistically. Clean things up whenever and wherever you get the chance.
• Refactor if you can make the change quickly (say, within a day).
• Only refactor when the pain of leaving it exceeds the pain of fixing it.
• Refactor immediately after shipping. (A great idea with very little likelihood of actually being followed.)