Asfar AliInstagram

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

1:49English(auto-generated)8 segments288 words · 1 min read

Search inside any video

SavedThat transcribes your saved videos and lets you search across all of them instantly. Save this video and find any moment.

TL;DR

Learn why refactoring based on assumptions can complicate code and how to reshape it effectively when real requirements arise.

refactoring code practicesclean code principlessoftware design requirementscode flexibility techniquesbest practices for refactoringhandling code changesoptimizing discount systemsprogramming logic improvements

Chapters

  1. 0:00Introduction to Refactoring
    01
  2. 0:10The Problem with Guessing
    02
  3. 0:30Simplifying with a Map
    03
  4. 0:50Handling Different Requirements
    04
  5. 1:10Reshaping Code for Flexibility
    05
  6. 1:30Conclusion and Best Practices
    06

Transcript

0:00

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.

0:14

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.

0:29

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.

0:44

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

1:01

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

1:17

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

1:31

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.

1:44

Follow for more clean code principles coming next.

Are you the creator or rights holder of this video? Request removal of this transcript.

Related Transcripts

Never lose a moment again

Save videos from YouTube, Instagram, and TikTok. Search everything that was said, and jump to the second.

Start Saving Videos - It's Free