Eurosport's Kodakademi #2
- 1. Eurosport Benjamin Baumann - @zentiltoutou https://github.com/bbaumann/Kodakademi 19/06/2017
- 2. Refactoring ! • What’s refactoring? « Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure ». « Improving the design of existing code » Refactor vs refactoring Hard, Error Prone, Risky Requires Energy + Time Save time on the long term, avoid bugs
- 3. Refactoring ! • Why refactoring? - Make the code easier to understand - Make the code cheaper to modify - Reassert the code structure/design - Find bugs - Write the code faster
- 4. Refactoring ! • When refactoring? - The rule of three - When adding a feature - When fixing a bug - During code reviews
- 5. Refactoring ! • When NOT refactoring? - Close to a deadline - Code does not work at all - Divide code in small components - For each component, choose refactor or rewrite - Not enough data on what is the code doing - Importance of tests, specs, knowledge - When refactoring implies changing external behaviour
- 6. Code smells ! • Practical case
- 8. Refactoring : exterminate duplicate code • DRY! Don’t Repeat Yourself. • Understanding the code : why is it duplicated? Why are they not exactly the same? • Modifying the code : may forget to change the duplicate • What to do ? Extract Method + Template Method.
- 9. Bad smells ! • Duplicate code • Long method • Large class • Long parameter list • Switch statements and abuse of conditional statements • Dead code
- 10. How to refactor effectively! • Write and use functional tests (Jenkins !) • Refactor often (every day!) • Make small changes step by step and commit them atomically • Believe in your tools and methods, even if transitional code is ugly « Refactoring is like doing a surgery while keeping the patient able to work on his daily chores » “Make small changes continuously, seizing opportunities to remold portions of a system when the time is right.”
- 11. Some refactoring recipes • Extract Method • Introduce explaining variable • Remove assignments to parameters • Move Method • Extract Class • Replace magic number with symbolic constant • Encapsulate collections
- 12. Good Practices • Self explanatory naming (variables, methods, class…) • DRY ! • Run « Code Metrics » & « Code Analysis » • Don’t abuse of « if » and « switch » • 1. Short methods. 2. Shorter methods. « rule of screen » • Interface/Contract and layers • Single Responsability!
- 13. Single Responsability • SOLID • Single Responsability • Open/Closed • LID • « A CLASS SHOULD HAVE ONLY ONE REASON TO CHANGE »
- 14. Single Responsability : Why ? • CHANGES ! • « Multi responsabilities lead to multi changes, changes lead to problems, problems lead to anger, anger leads to the dark side »
- 15. Single Responsability : Exemple • List.cs : 1137 hairy loc • Enumerator.cs : 4 fields, 67 loc . Shared with other collections
- 16. OOP Principles from Single Responsability • Separate your code by layers • Program to interfaces, not implementations • Depend on abstraction. Do not depend on concrete classes • Strive for loosely coupled designs between objects that interact • Least Knowledge : « talk only to your immediate friends »
- 17. Using Single Responsability • SOLID and design patterns are Tools • Need to know when and how to use them • Carpenter’s metaphore • What NOT to do : « Creating random boundaries between objects, using patterns wherever you can »
- 18. Single Responsability : Clean Architecture • Separate your code by layers • Put abstraction in the inner layers • Put implementation details in the outer layers • Dependencies can only point inward, never outward
- 19. Exemple • 5 concepts ! • App • Config • S3 • Flysystem • Eloquent ORM) • Different languages • Like reading a book which switches languages
- 20. Exemple • Remove what is not application focussed (storing/getting users + images) • Create interfaces (integration points) • Use tools
- 21. Clean Architecture : Benefits • Independent of Frameworks (=tools, not core) • Testable (Business Logic can be tested without the UI) • Independant of UI • Independant of Database • Independant of any external agency • Independant of everything • Loose coupling !
- 22. Conlusion • Keep It Simple Stupid (KISS) • Refactor whenever you have time • Refactor little step by step • A class should have only one reason to change • Keep core/entities free of dependencies • Use tools with caution
- 23. Shamefully copied from • https://dev.to/barryosull/cleaning-up-your-codebase-with-a-clean- architecture • https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean- architecture.html