Refactoring 101

We hate to refactor. (The practice of altering code to make it cleaner, simpler, and sometimes faster, while not altering functionality.) Adam Culp will talk about how to do it better, and will discuss: When to refactor. How to refactor. Why refactor. How a refactor can help us write better code in the future. A common methodology and steps to follow while refactoring, and resources to help us all on our refactor journey.

Transcript

1. Refactoring 101 By: Adam Culp Twitter: @adamculp https://joind.in/14927
2. 2 Refactoring 101 • About me – PHP 5.3 Certified – Consultant at Zend Technologies – Organizer SoFloPHP (South Florida) – Organized SunshinePHP (Miami) – Long distance (ultra) runner – Judo Black Belt Instructor
3. 3 Refactoring 101 • Fan of iteration – Pretty much everything requires iteration to do well: • Long distance running • Judo • Development • Evading project managers • Refactoring!
4. 4 Refactoring 101 • About talk – Based on “Refactoring; Improving The Design of Existing Code” book, by Martin Fowler. – https://github.com/adamculp/refactoring101 – for PHP code samples
5. 6 Refactoring 101 • What is “refactoring”? – “...process of changing a computer program's source code without modifying its external functional behavior...” en.wikipedia.org/wiki/Refactoring – Should not add functionality – Simplify code – Improve code readability
6. 7 Refactoring 101 • Two hats – Adding Functionality Hat – Refactoring Hat – We add functionality, then refactor, then add more functionality ...
7. 8 Refactoring 101 • Then optimize – Do not optimize while refactoring – Separate step – Refactoring is NOT optimizing
8. 9 Refactoring 101 • Why refactor? – Prevent decay – Preserve or fix design – Reduce duplication – Improve maintainability – Helps us code faster – Locate bugs – Code smells
9. 10 Refactoring 101 • Code “smells” – What are “smells”? • Indications of spoiled code nearby • Not conclusive • The “smell” is not bad
10. 11 Refactoring 101 • Code “smells” – “Smells” hinting a refactor may be needed: • Duplicate Code (rule of 3) • Long Methods • Large Class • Long Parameter (argument) List • Divergent Change – cascade change to accommodate another • Shotgun Surgery – change ripples as bugs • Feature Envy – method uses parts from other class • Switch Statements – sacrifice polymorphism
11. 12 Refactoring 101 • Code “smells” – Cont'd: • Lazy Class – class not doing much • Speculative Generality – something built for possible future • Temporary Field/Variable • Message Chains – object asking object asking object • Middle Man – directors in place but serve no real purpose • Inappropriate Intimacy – classes share private parts • Data Class – getters and setters, but nothing else • Comments – where comments cover bad code
12. 14 Refactoring 101 • Tools to highlight smells – PHPqatools.org • PHPUnit • PHPLoc • PHP_Codesniffer • PHP_Depend • PHP Copy/Paste Detector • PHP Mess Detector • PHP Dead Code Detector
13. 15 Refactoring 101 • Realtime profiling – Zend Z-Ray
14. 16 Refactoring 101 • Rewrite vs Refactor – Rewrite = perceived easy road – Refactor = best teacher – Business arguments • Budget • Time • Retain business logic
15. 17 Refactoring 101 • When to rewrite – Want a new app • Not just better coded current app – Business logic change – Target market change – Framework integration or change
16. 18 Refactoring 101 • When to refactor? – No “special” time – Short bursts – Refactor to gain something – Prior to adding functionality – When fixing a bug – During code review
17. 19 Refactoring 101 • What do I tell my manager? (justification) – Tech savvy manager = not be hard to explain the benefits. – Quality centric manager = stress quality aspects. • Introduce as a review process. • Many resources on Google. – Schedule driven manager = Don't tell (controversial?). • Find a way to work it in. • Overall it saves time, but some will never “see” it.
18. 20 Refactoring 101 • First steps – Use source control (Git, SVN, etc.) • Records steps, provides rollback • Auditable – GET IT WORKING • Do NOT refactor broken – Create consistent data – Create tests
19. 21 Refactoring 101 • Tests and refactoring – Basic refactor steps • Ensure tests pass • Plan refactor • Implement • Ensure tests still pass – Updating tests if needed – Add more tests to cover newly discovered items • Repeat!
20. 22 Refactoring 101 Let's look at the code! • Example – Lets look at a code example. – Tips and descriptions during steps. – Our Task: • Video Rental Company has asked for an HTML representation of their customer statement to be created.
21. 23 Refactoring 101
22. 24 Refactoring 101
23. 25 Refactoring 101
24. 26 Refactoring 101
25. 27 Refactoring 101
26. 28 Refactoring 101
27. 29 Refactoring 101 • Code summary: What did we see? – Method statement() → • Too long • Not reusable for HTML version • Switch sacrificing polymorphism • Determining class/type • Calculating rental price, frequent renter points, grant total
28. 30 Refactoring 101 • Additional notes – Cannot change how movies are classified. – Customers always changes, not easy in current state. • Movie classification • Frequent renter points • Rental days per type • Price calculation
29. 31 Refactoring 101 • Objective: – Clean up statement(). • Shorten – Extract code to encapsulate functionality – Extract business logic to keep DRY
30. 32 Refactoring 101 • TEST ! ! !
31. 33 Refactoring 101 • Extract method – Moves a functionality to it's own method. • Encapsulate calculation of each rental. • Shorten statement() method.
32. 34 Refactoring 101 • Extract method cont'd. – We now have a new method amountFor().
33. 35 Refactoring 101 • Rename variables – Renaming $each to $rental – Improves readability. – Relate intent.
34. 36 Refactoring 101 • Renaming variables, cont'd. – Renamed $each to $rental, and also changed $thisAmount to become $result for clarity.
35. 37 Refactoring 101 • Rename method – Rename amountFor() to getCharge(). – Self documenting.
36. 38 Refactoring 101 • Move method – Move getCharge() from Customer to Rental. • Relies on Rental data. – Already have Rental object, no need to pass $rental.
37. 39 Refactoring 101 • Move method cont'd – Now calls getDaysRented() directly. – Returns charge of Rental, as it should. • Building rental charge in customer was misplaced.
38. 40 Refactoring 101 • Replace temp with query – Remove temporary variable and call Rental->getCharge() direct. • Less future maintenance. • Makes code clearer.
39. 41 Refactoring 101 • Extract method – $frequentRenterPoints calculation extracted to getFrequentRenterPoints(), and move it in the Rental class.
40. 42 Refactoring 101 • Replace temp with query – Encapsulate logic and generation of grand total. – Promotes DRY. – Remove $totalAmount temporary variable.
41. 43 Refactoring 101 • Replace temp with query – Encapsulate logic and generation of frequent renter points. – Promotes DRY. – Remove $frequentRentalPoints temporary variable.
42. 44 Refactoring 101 • Create HTML statement – Create HTML version. – Rename original as text version.
43. 45 Refactoring 101 • Execution – Can call either Text or HTML versions.
44. 46 Refactoring 101 • Recap – Most refactoring reduces code • More self-documenting • More flexibility • More testable – 3 loops (getFrequentRenterPoints, getTotalCharge, and statement) • Isolates calculations • Enabled multiple statements (text/html) – Optimizing and refactoring = different • Refactor, then optimize – Future = separation of concerns
45. 59 Refactoring 101 • Conclusion – Do not refactor a broken application – Always have tests in place prior to refactor • Unit tests or • Functional tests or • Manual tests – Leave code cleaner than you got it – Try NOT to rewrite – Learn to “smell” problems – Love iteration!
46. • Thank you! – Code: https://github.com/adamculp/refactoring101 – Please rate at: https://joind.in/14927 Adam Culp http://www.geekyboy.com http://RunGeekRadio.com Twitter @adamculp