Surgical Refactoring

This is a skill that takes practice. The following video is an excellent introduction into why this is important and how to do this

• Video https://www.slideshare.net/NellShamrell/first-do-no-harm-surgical-refactoring
• Slide deck https://www.youtube.com/watch?v=w6n9YR3o-7Q

The essence of this idea is to make sure that your refactoring is small and contained and doesn’t make changes that blast through the code

Example

You are working on a job to modify an endpoint and discover that there are 20 endpoints pull of cut and paste code abuse with methods that are a hundred lines long each. It is clearly impossible to unit test the business logic in these methods.

• Don’t try and fix all 20, just fix the one that you have a business need to modify
• If your refactoring browser suggests changes to other endpoints consider accepting these changes as they are probably safe
• Try and do minimum impact
• Do lots of little refactors, and run the tests between each refactor
• Don’t put off running the tests: the tests should constantly be passing if you are using this technique correctly
• Every time you extract a testable piece of code, write tests for it now and not at the end of the refactor
• Don’t feel you have to ‘make the refactor perfect’: use the boy scout rule and leave the code cleaner than you left it
• Communicate what you have done with the rest of the team, so that if they are working on some other endpoints they can use the same approach, and reuse the new abstractions and testing approach

Links demonstrating large Java refactorings

• <ppt/refactoring/performExecute.pptx>
• <ppt/refactoring/updateAddress.pptx>