Don’t refactor on a guess: wait for a real requirement, reshape the code to…

Most refactoring starts the same way. You spot messy code and you clean it up. But when you refactor on a guess, you can end up adding awkward conditions just to make the next requirement fit. Take this discount system. Each coupon applies a different percentage off the price.

These cases all do the same calculation, only the percentage changes. To simplify, we can put the percentages in a map and replace the switch with one formula. Now, adding another percentage coupon takes just one new entry.

But what if the next coupon takes a fixed amount off the price? Now the function needs a condition to choose which calculation to use. When we design around a guess, each new requirement can push the code further from the simplicity we wanted.

So instead of guessing what comes next, let's go back and wait for a real requirement. If the change fits the logic we already have, we can simply add it. But if the change needs different logic, first reshape the code without changing its behavior

so the new logic can be added separately. Here we move the percentage calculation into its own class. We give each coupon its percentage, then let the function delegate the calculation. Now we can add the new behavior in its own class

without changing the calculation that already works. The real change showed us where we needed flexibility. Now the refactor supports other variations too. So if the code already works, we can leave it alone until a real requirement

gives us a reason to refactor. Then we make room for that change without altering the existing behavior and then add the new feature. Follow for more clean code principles coming next.

Follow for more clean code principles coming next.