Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Refactoring Workflows & Techniques Presentation by Valentin Stantescu

282 views

Published on

PayU ekibimizden Valentin Stantescu'nun PHP İstanbul Konferansı'nda 'Refactoring Workflows & Techniques' hakkında yapmış olduğu sunuma buradan ulaşabilirsiniz.

PayU hakkında detaylı bilgi için tıklayın; www.payu.com.tr

Published in: Services
  • Be the first to comment

Refactoring Workflows & Techniques Presentation by Valentin Stantescu

  1. 1. Refactoring Workflows & Techniques Valentin Stăncescu
  2. 2. About Me  Software Developer  +7 years experience with PHP  Worked for biggest online publisher in Romania building platforms that handles ~1million unique visitors / day  Experienced in online payments industry building key new features like Token or One Click payments  Experience in dealing with legacy code, refactoring and rearchitecture  Agile SCRUM enthusiast
  3. 3. Today’s presentation summary  Short introduction about PayU Gecad platform  Refactoring workflows  Refactoring techniques  Refactoring rules  SOLID principles  Q&A
  4. 4. PayU Gecad facts  First line of code written in 2004  About 600k lines of code  About 600 database tables  Today, PayU Gecad platform turned to be a SOA platform, covered with tests in all it’s public APIs
  5. 5. Refactoring workflows
  6. 6. What is Refactoring “Is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. “ Martin Fowler
  7. 7. When to do refactoring?  On legacy code - LITTER PICKUP REFACTORING  Hard to understand code, when time spent to understand code is greater than the time to redo the code – COMPREHENSION REFACTORING  For code that was initially well written, when we try to add new functionality we realize it needs to be refactored – PREPARATORY REFACTORING
  8. 8. Legacy Code  Not covered by unit tests  No automated test  Badly written code  Hard to maintain code  Hard to understand
  9. 9. Refactoring is NOT  Removing bugs  Re-engineering  Modifying old code  Adding new features No functionality or bug should be changed during refactoring!
  10. 10. Refactoring techniques
  11. 11. Refactoring techniques  Extract Method  Move Methods  Extract Class  Replace Arrays with Objects
  12. 12. Refactoring rules
  13. 13. Refactoring rules  Identify code to refactor  Copy code to new method  Write unit tests for the code  Verify tests pass  Reroute old code to new method  Verify tests pass  Delete old code  Test manually
  14. 14. Pyramid of tests
  15. 15. How to apply tests on legacy code  Start writing Functional and Integrated tests. Use the integrated tests as a safety net  When enough coverage, break the dependencies  When dependencies are separated, write component tests and integration tests  Refactor  Write Unit Tests  Test the platform manually
  16. 16. SOLID Principles
  17. 17. What are SOLID principles  Made popular by Robert C Martin in early 2000s  Are 5 basic principles of OOP  Their purpose is to create a system that’s easy to maintain and extend over time
  18. 18. SOLID achronym  Single Responsibility Principle  Open/Closed Principle  Liskov Substitution Principle  Interface Segregation Principle  Dependency Inversion Principle
  19. 19. Single Responsibility Principle  Every module or class should have a single responsibility, and that responsibility should be entirely encapsulated by the class.  “A class should have only one reason to change.” – Robert C. Martin
  20. 20. Single Responsibility Principle Violations  Generic class names (Please keep in mind that naming is very important in a large application)  Methods in class that are doing various things (make calculations, executes SQLs, etc)  Method names to contain ‘AND’, ‘OR’
  21. 21. Single Responsibility Principle Example class CPaymentGateway { public function SetTerminalId(){...} public function SetTerminalSettings(){...} public function GetTerminalIdByTerminal(){...} public function GetTerminalID(){...} public function GetTerminalSettings(){...} public function SetCardData(){...} public function RequestAuthorization(){...} public function HandleResponse(){...} public function TranslateResponse(){...} public function SetCallbackParams(){...} public function SetPayType(){...} public function ProcessAuthorization(){...} public function onAuthorizationSuccess(){...} public function onAuthorizationFail(){...} public function doAuthorization(){...} [...] }
  22. 22. Single Responsibility Principle Example 2 class TerminalService { //public function SetTerminalId(){...} //public function SetTerminalSettings(){...} public function GetTerminalIdByTerminal(){...} public function GetTerminalID(){...} public function GetTerminalSettings(){...} } class Response { public function HandleResponse(){...} public function TranslateResponse(){...} //public function SetCallbackParams(){...} }
  23. 23. Single Responsibility Principle Example 3 class Card { public function __construct($cardNumber, $cardCVV, $cardExpMonth, $cardExpYear, $cardHolderName) //public function SetCardData(){...} [...] } class AuthorizationService { public function RequestAuthorization(){...} public function ProcessAuthorization(){...} public function onAuthorizationSuccess(){...} public function onAuthorizationFail(){...} public function doAuthorization(){...} [...]  }
  24. 24. Open Closed Principle  Every class or module, should be opened for extension but closed for modification.  Do not modify a class or module to extend its behavior  You can extend and interface or inherit class  Used dependency injection in class
  25. 25. Liskov Substitution Principle  Children classes should not change any parent’s significant behavior  Significant behavior is the one that cannot be changed by any children classes (core functionality)  Children classes should respect the contracts of their parents
  26. 26. Interface Segregation Principle  No class should be forced to depend on methods it does not use  Use small interfaces, no “fat” ones with lots of methods
  27. 27. Interface Segregation Principle Example class Bird { public function fly(); public function eat(); } class Duck extends Bird { public function fly(){...} public function eat(){...} } class Penguin extends Bird { public function fly(){} public function eat(){ … } }
  28. 28. Interface Segregation Principle Example 2 interface FlyInterface { public function fly(); } class Duck implements FlyInterface, EatInterface { public function fly(){...} public function eat(){...} } class Penguin implements EatInterface { public function eat(){ … } } interface EatInterface { public function eat(); }
  29. 29. Dependency Inversion Principle  Core and high level modules should not depend of low level modules  Both should depend upon abstraction  Use interfaces to interconnect modules
  30. 30. Other Refactoring Useful things we are using  Feature toggles  Comparing toggles  Fast deployment for an easy integration between refactoring and new features
  31. 31. That’s all folks! Thank you!  Q&A  Email: valentin.stancescu@payu.ro

×