Refactoring PHP
7 likes3,173 views
This document is a presentation on refactoring code. It discusses refactoring an existing movie rental application to improve its design. The presenter walks through refactoring steps like extracting methods, replacing temporary variables with method calls, and moving code to more appropriate classes. The goals of refactoring are to simplify code, reduce duplication, and make it easier to understand and modify. Code "smells" that indicate needs for refactoring are also outlined. The presenter emphasizes that tests are crucial to refactoring to prevent introducing bugs.
Refactoring PHP
- 1. Refactoring Presentation for: South Florida PHP Users Group By: Adam Culp Twitter: @adamculp http://www.geekyboy.com
- 2. Refactoring Based on popular “Refactoring” Improving The Design of Existing Code book, by Martin Fowler. We will start in the code with an example. Tips and descriptions will be handled during the example. In the example we are tasked with creating an HTML representation of the customer statement for a movie rental.
- 3. Refactoring Movie class With a new project we take a look at the current application a customer has requested to be changed. We start with the Movie class.
- 4. Refactoring Rental class Next we look at the Rental class.
- 5. Refactoring Customer class p1 With a new project we take a look at the current app that is about to be changed. Next we look at part 1 of the Customer class.
- 6. Refactoring Customer class p2 With a new project we take a look at the current app that is about to be changed. Next we look at part 2 of the Customer class.
- 7. Refactoring Not terrible for a small quick and dirty application, but if part of a larger application we have problems. Customer class doing far too much, and statement method is too long. Impossible to reuse the statement for an HTML representation. The customer also wants to be able to change how they classify movies. As experienced developers we know that customers will always come back six months from now and want it changed in some way.
- 8. Refactoring Rewrite vs Refactor Budget constraint Time constraint Rewrite is an excuse to NOT dig in someone's code Refactor is the best teacher
- 9. Refactoring First step Build tests based on current “working” application, so we can verify if we break something. Pre-load database with data or create fixtures needed for tests, to ensure we have a constant to compare test results. If we are not starting with a working application you must first get the application working prior to refactoring. Do not try to refactor a broken application or you risk breaking it further, and end up with a total rewrite.
- 10. Refactoring Step 1 Extract Method to move switch statement to its own method.
- 11. Refactoring Step 2 Variable names should make sense. (each > rental, thisAmount > result)
- 12. Refactoring Step 3 Extract Method amountFor() to Rental class. It uses information from Rental, but no information from Customer. We rename it to more meaningful getCharge().
- 13. Refactoring Step 4 Call getCharge() directly from statement() instead of using amountFor() as a middle man method.
- 14. Refactoring Step 5 Replace Temp with Query - Cleanup of call to getCharge(). Eliminate temp variables by calling method direct. Less maintenance.
- 15. Refactoring Step 6 Extract Method and move frequentRenterPoints to its own method in Rental class where it logically belongs.
- 16. Refactoring Step 7 We do Replace Temp with Query for totalAmount. Temp variables can be a problem and really only serve a purpose within their own routine and encourage long, complex routines.
- 17. Refactoring Step 8 Also do Replace Temp with Query on frequentRentalPoints to eliminate more temp variables.
- 18. Refactoring Step 9 We are now able to create the HTML version of the statement, and we rename the original to represent a Text version.
- 19. Refactoring Recap Most refactoring reduces code, while we increased it for this example. We also duplicated a loop to make it happen 4 times instead of once. (getFrequentRenterPoints, getTotalCharge, getTotalFrequentRenterPoints) Optimizing and refactoring are different actions. Refactor first, then optimize later if needed. More refactoring could further clean up Text and HTML statements to DRY it up. (split out header/footer, etc.) Still need more refactoring to allow classification changes by the customer.
- 20. Refactoring Step 10 Move Method on getCharge() because it uses data in Movie, so should be in the same class as the data.
- 21. Refactoring Step 11 Replace Conditional with Polymorphism on getCharge() because it uses data in Movie, so should be in the same class as the data.
- 22. Refactoring Two hats Adding Function Hat Refactoring Hat First we add functionality, they we refactor it, then add more functionality, ...
- 23. Refactoring Why Refactor? Without refactoring code decays As code is changed it loses structure, making it harder to see design Regular refactoring preserves design Poorly designed = more code due to duplication Reduced code = easier to maintain Reduced code = easier to understand Helps find bugs Helps us program faster
- 24. Refactoring When to Refactor? Should not set aside time to refactor, it is just something we do in short bursts Refactor because you want to do something, and refactoring helps you do it Often a quick refactor can help developing new functionalities move faster Rule of Three → see next slide
- 25. Refactoring Rule of Three When you add function Helps to learn code you need to modify Changes code that prevents the addition When you need to fix a bug Make code more understandable Usually highlights the bug During code review Code looks good to developer, but maybe not to the team. More concrete results
- 26. Refactoring What do I tell my manager? For a tech saavy manager it may not be hard to explain the benefits Quality centric manager stress quality aspects Perhaps introduce it as a review process There are many resources on Google about value of reviews, inspections, or software development process Schedule driven … Don't tell (controversial?) Find a way to work it into scheduling. Overall it saves time, but some will never “see” it
- 27. Refactoring Code “smells” as indicators Bad code “smells” and is a great way of indicating it is time for a refactor. Duplicate Code Long Method Large Class Long Parameter (argument) List Divergent Change - if change is needed in multiple areas to accommodate a change Shotgun Surgery – change causes ripple of other needed changes Feature Envy – a method seems to use another class instead of the one it is in
- 28. Refactoring Code “smells” as indicators More “smells” Data Clumps – if data items tend to accompany one another Primitive Obsession Switch statements Parallel Inheritance Hierarchies – caused when you need to create a subclass of one object because you created a subclass of another Lazy Class – classes that do not do much and do not pay for their extra weight Speculative Generality – constructs built for the sake of possibility later
- 29. Refactoring Code “smells” as indicators More “smells” Temporary Field Message Chains – object asking for object that asks for another object... Middle Man – directors in place but serving no real purpose Inappropriate Intimacy – classes should not deal too much with each others private parts Data Class – getters and setters, but nothing else Comments – where comments are used as deodorant to cover a bad smell
- 30. Refactoring Tests and Refactoring You cannot properly refactor without tests in place. Writing tests is the first step of refactoring, and should happen as you write the code in the first place. (or before, as with TDD)
- 31. Refactoring Thank you Adam Culp http://www.geekyboy.com http://github.com/adamculp Twitter @adamculp