- Identify areas of code that need to be refactored
- Utilize arguments and parameters to DRY up code
DRYDon’t Repeat Yourself!
refactorRewriting working code for readability, maintainability, or performance without changing it’s behavior
Turn + Talk
Talk with your partner: If someone says, “this needs to be refactored”, what might they see that makes them say that?
Then, scroll through this
main.js for a Number Guesser project (do NOT clone it down right now), and take note of 2-3 opportunities for refactoring.
Modeling a Refactor
As you watch a real person refactor in real time, take note of the questions they ask themselves and the things they consider.
It’s Not A Race
Refactoring is more of an art. It should not be rushed.
You should be following the red-green-refactor flow, just as you do with TDD. Refactoring is the step we take after things work. The code is ok, but the goal of this process is to make it great. To do this well, great developers are methodical and thorough.
With the repo you select based on the level of heat you want, take these steps:
- Make sure you are familiar with the current functionality (i.e., run the app in the browser!)
- There are many refactoring opportunities here. List all the ones you see out.
- With your partner, decide on one area to focus your energy.
- Rubber duck it - what do you know? Which parts seem almost
impossibleright now? Takes notes in notebook or with comments to start chipping away at the challenge.
- Once you feel like you are done, ensure that the app is behaving as it originally was in the browser. Make sure to clean up any old comments, old code, whitespace, etc.
Mild: Clone down this repo. Medium: Use your Hang in There repo Spicy: Ask another group for the link to their repo