Is there a specific signal you look for before refactoring?
For example:
High complexity?
Hard to understand logic?
Bugs increasing?
Curious how different developers decide this 🤔
10 views
Replies
Best
For me, it's the 'Rule of Three'. If I have to copy-paste similar logic a third time, it gets abstracted. Aside from that, I usually only refactor if a specific file has become a bottleneck for shipping new features. If it's ugly but it works and rarely needs touching, I leave it alone. 'Tech debt' only matters if you are actually paying interest on it!
@arotar That’s a great point — especially the “Rule of Three” 👌
I’ve noticed the same pattern, but sometimes complexity builds up before we even realize it (especially with nested logic and edge cases).
That’s actually one of the reasons I started working on Complexity Indicator — to catch those signals early instead of waiting until it becomes a bottleneck.
Curious — do you think having real-time complexity feedback while coding would change how you approach refactoring?
Replies
Complexity Indicator
@arotar That’s a great point — especially the “Rule of Three” 👌
I’ve noticed the same pattern, but sometimes complexity builds up before we even realize it (especially with nested logic and edge cases).
That’s actually one of the reasons I started working on Complexity Indicator — to catch those signals early instead of waiting until it becomes a bottleneck.
Curious — do you think having real-time complexity feedback while coding would change how you approach refactoring?