O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Object Calisthenics for Magento - Meet Magento New York 2017

393 visualizações

Publicada em

Object Calisthenics for Magento - Meet Magento New York 2017

Publicada em: Tecnologia
  • Seja o primeiro a comentar

Object Calisthenics for Magento - Meet Magento New York 2017

  1. 1. CLEAN CODE, OBJECT CALISTHENICS & BEST PRACTICES   -  by#MM17NYC @mhgontijo
  2. 2. Matheus Gontijo Y-E-E-A-A-H-H, we have a #Brazilian in the house, folks! So ware Engineer at Over 6 years of experience with Magento platform Speaker and attendee to conferences all over the world on twitter - ping me there   ;- D Crimson Agility MCD & MCD+ @mhgontijo
  3. 3. What KILLS So ware Developers so badly?
  4. 4. uhmm... there are  PLENTY  some guys still writing code in our community like that...
  5. 5. Poorly written code equals... 💩💩💩 countless hours of energy being drained HUGE amount of time wasted === MONEY wasted ...it's unpleseant... it discourages the entire team to work with that mess
  6. 6. How can we improve our code? EXERCISING!
  7. 7. Object Calisthenics! btw has anybody ever heard about it?
  8. 8. Cal • is • then • ics /ˌkaləsˈTHeniks/ Greek word that means gymnastic exercises.
  9. 9. The concept was created by Jeff Bay in his book The ThoughtWorks Anthology A collection of exercises to focus on maintainability, readability, testability, and comprehensibility of your code.
  10. 10. PHP Community? Rafael Dohms - Keynode Speaker, Evangelist, and founder of PHPSP & PHPAmsterdam... which are awesome! Guilherme Blanco - Core Committer at Doctrine, Symfony and Zend Framework @rdohms @guilhermeblanco
  11. 11. THAT SHOULDN'T BE EXTREMELY... COMPLEX!!!
  12. 12. 9 simple rules to write code... WAY BETTER ✌
  13. 13. 9 simple rules advices to write code... WAY BETTER ✌
  14. 14. BUT don't follow them blindly.... It's NOT binary: RIGHT or WRONG There is not one-size-fits-all No Silver Bullet Don't take what I'm saying as absolute truth   :- P the main goal is to challenge yourself... to make you RE-think the way you code...
  15. 15. 30 minutes only just going through quickly    ; ) the examples are very simple just for the sake of easy understanding
  16. 16. #01 ADVICE Only One Level Of Indentation Per Method
  17. 17. Example: Let's say you are creating a process to update description
  18. 18. Benefits: Easy to understand! Single Responsibility Principle ("S" in S.O.L.I.D.) Encourages Re-use
  19. 19. #02 ADVICE Don't Use The ELSE Keyword
  20. 20. Example: Let's create a class in order to subscribe emails to a newsletter group called VIP.
  21. 21. Rules: It has to be a valid email. The email can not be registered again, if it already is. The email has to have a customer assigned the same email. The customer assigned to that email needs to be assigned to VIP Group also.
  22. 22. Benefits: Decreases Cyclomatic Complexity Prevents Code Duplication Legibility (Single Path)
  23. 23. #03 ADVICE Wrap All Primitives Types And Strings, If It Has Behavior
  24. 24. When? When your type needs validations, business rules or behaviors Email Zipcode Phone Number IP Address IBAN, ISBN URL List of status as Pending, Denied, Approved ...
  25. 25. Example: Let's say you are creating a class to send emails.
  26. 26. Benefits: Type Hinting Encapsulation of business rules Prevents Code Duplication Implements Value Objects of DDD
  27. 27. #04 ADVICE First Class Collections
  28. 28. Benefits: Single Responsibility Principle ("S" in S.O.L.I.D.) Implements SPL Interfaces Class for Filtering, Mapping, Ordering & other
  29. 29. #05 ADVICE One Dot Per Line
  30. 30. #05 ADVICE One Dot "->" Per Line
  31. 31. Law of Demeter
  32. 32. *** EXCEPT *** for Fluent Interfaces/Method Chaining since it was designed to work that way
  33. 33. Benefits: Law of Demeter Legibility
  34. 34. #06 ADVICE Don't Abbreviate
  35. 35. Benefits: Legibility Maintainability
  36. 36. #07 ADVICE Keep All Entities Small
  37. 37. Long files are hard to read... so... No methods with over 20 lines No namespaces over 15 files Class with 200 lines maximum Very challenging!
  38. 38. Benefits: Legibility Maintainability
  39. 39. #08 ADVICE No Classes With More Than Two Five Instance Variables
  40. 40. Benefits: Higher Cohesion Lower Coupling Shorter Dependency list Maintainability
  41. 41. #09 ADVICE No Getters and Setters! just my favorite ❤ ❤ ❤
  42. 42. Example: Let's create a approval process for comments.
  43. 43. It's very important to the system to track the following: Previous Status New Status User that made the change Date
  44. 44. John is creating the a new approval record... Status: PENDING
  45. 45. Mary is creating the a new approval record... Status: PENDING ---> FIX_TYPO
  46. 46. David is creating the a new approval record... Status: FIX_TYPO ---> APPROVED
  47. 47. h4ck3r is creating the a new approval record... Status: APPROVED ---> APPROVED
  48. 48. h4ck3r is creating the a new approval record... Status: DENIED ---> DENIED
  49. 49. Solution? ENCAPSULATION! We have to HIDE business logic! BTW it's not something new... it's just encapsulation... basic concept of OOP
  50. 50. Now nobody will no longer be able to mess up the process    ;- D
  51. 51. That's it! ✌ ✌ ✌ ✌
  52. 52. Recap 1. Only One Level Of Indentation Per Method 2. Don't Use The ELSE Keyword 3. Wrap All Primitives Types And Strings, If It Has Behavior 4. First Class Collections 5. One Dot "->" Per Line 6. Don't Abbreviate 7. Keep All Entities Small 8. No Classes With More Than Two Five Instance Variables 9. No Getters and Setters!
  53. 53. and the most important thing is...
  54. 54. You should give Object Calisthenics a try! Take a month and see how good that is!
  55. 55. Questions? @mhgontijo

×