Se ha denunciado esta presentación.
Se está descargando tu SlideShare. ×

Software Craftmanship - Cours Polytech

Cargando en…3

Eche un vistazo a continuación

1 de 66 Anuncio

Más Contenido Relacionado

Similares a Software Craftmanship - Cours Polytech (20)

Más de yannick grenzinger (18)


Más reciente (20)

Software Craftmanship - Cours Polytech

  1. 1. Yannick Grenzinger @ygrenzinger
  2. 2. Some history
  3. 3. Typical flow of development (before)
  4. 4. Scrum
  5. 5. What is craft ?
  6. 6. But really for me as a developper, why craft is important ?
  7. 7. Working software is not enough
  8. 8. You don’t like code without it
  9. 9. “I could list all of the qualities that I notice in clean code, but there is one overarching quality that leads to all of them. Clean code always looks like it was written by someone who cares. There is nothing obvious that you can do to make it better.” Michael Feathers, author of Working Effectively with Legacy Code
  10. 10. Principles ● Quality : Simple Design (DDD, OO), clean code, refactoring, Tests (maybe TDD) ● Humility : I question myself and continuously improving ● Sharing : code review, pair (or mob) programming, collective code ownership ● Pragmatism : I understand the constraints and adapt myself if necessary ● Professionalism : I treat my client as a partner (principle of "courage" from XP) ● Boy Scout rule : "Always leave the campground cleaner than you found it."
  11. 11. Test First
  12. 12. Unit tests and TDD
  13. 13. Why ?
  14. 14. Pyramid of tests
  15. 15. Why ? ● Fast feedback when you’re coding or on your continuous integration tool ● Best entry point for a new developer ○ Best documentation (always up to date) ○ Use by example of the API (the public method you expose on your classes) ● Safety net for future change
  16. 16. Unit Tests - FIRST Principle ● Fast: run (subset of) tests quickly (since you'll be running them all the time) ● Independent: no tests depend on others, so can run any subset in any order ● Repeatable: run N times, get same result (to help isolate bugs and enable automation) ● Self-checking: test can automatically detect if passed (no human checking of output) ● Timely: written about the same time as code under test (with TDD, written first!)
  17. 17. How to write ? ● Test behaviors, not method ● Each test have a clear intention : should_do_when_conditions ● 3 A’s rule: ○ Arrange (Given) all necessary preconditions and inputs ○ Act (When) on the object or method under test ○ Assert (Then) that the expected results have occurred ● You should begin by the intention, the Assert/Then
  18. 18. TDD loop OVERVIEW Analyse problem Guiding tests list RED Declare & Name Arrange, Act & Assert Satisfy compiler GREEN Implement simplest solution to make the test pass REFACTOR Remove code smells and improve readability No new functionalities
  19. 19. Double loop
  20. 20. Kata “classic” lists
  21. 21. Leap Year Kata Write a function that returns true or false depending on whether its input integer is a leap year or not. A leap year is divisible by 4, but is not otherwise divisible by 100 unless it is also divisible by 400. ● 2001 is a typical common year ● 1996 is a typical leap year ● 1900 is an atypical common year ● 2000 is an atypical leap year
  22. 22. Old Good One - FooBarQix Write a program that displays numbers from 1 to 100. A number per line. Follow these rules: ● If the number is divisible by 3, write "Foo" ● If the number is divisible by 5, write "Bar". ● If the number is divisible by 7, write "Qix". ● Else return the number converted to string
  23. 23. Old Good One - FooBarQix Write a program that displays numbers from 1 to 100. A number per line. Follow these rules: ● If the number is divisible by 3, write "Foo" ● If the number is divisible by 5, write "Bar". ● If the number is divisible by 7, write "Qix". ● Else return the number converted to string ● If the string representation contains 3, write "Foo" for each 3. ● If the string representation contains 5, write "Bar" for each 3. ● If the string representation contains 7, write "Qix" for each 3.
  24. 24. Old Good One - FooBarQix Write a program that displays numbers from 1 to 100. A number per line. Follow these rules: ● If the number is divisible by 3 or ● If the string representation contains 3, write "Foo" instead of 3. ● If the number is divisible by 5 or contains 5, write "Bar" instead of 5. ● If the number is divisible by 7 or 7 contains, write "Qix" instead of 7. More specs: ● We watch the dividers before the content (eg 51 -> FooBar) ● We look at the content in the order in which it appears (eg 53 -> BarFoo) ● We look at the multi in the order Foo, Bar and Qix (eg 21 -> FooQix) ● 13 contains 3 therefore wrote "Foo" ● 15 is divisible by 3 and 5 and contains a 5 therefore written "FooBarBar" ● 33 contains twice 3 and is divisible by 3 therefore written "FooFooFoo"
  25. 25. Clean Code
  26. 26. A lots of principles ● Have clear intention ● Formating ● Naming ● SOLID ● YAGNI ● KISS ● Demeter’s law or “Tell don’t ask” ● Donald Norman’s Design Principles
  27. 27. Naming - the most difficult ● Understand the functional side ● Building common (“ubiquitous”) language ● Use intention revealing name ● Use clear and known mental mapping ● For class names, use nouns and avoid technical noisy term like Manager, Data ● Method names should have a verb
  28. 28. SOLID principles ● Single Responsibility ● Open / Closed ● Liskov Substitution ● Interface Segregation ● Dependency Inversion
  29. 29. Single Responsibility Principle - SRP only one potential change in the software's specification should be able to affect the specification of the class ● a class should have only a single responsibility / purpose ● all members in a class should be related to this responsibility ● If a class has multiple responsibilities, it should be divided into new classes Surely breaking the principle if you have : ● A very big class (Line of Code, Total of methods metrics) ● A lack of cohesion of methods (LCOM4 metric)
  30. 30. SRP not respected
  31. 31. SRP respected
  32. 32. Open / Closed Principle - OCP “software entities … should be open for extension, but closed for modification” - Bertrand Meyer ● Once a module has been developed and tested, the code should only be adjusted to correct bugs (closed). ● However it should be able to extend it to introduce new functionalities (open). Surely breaking the principle if you have : ● A high cyclomatic complexity ● Too much conditionals instruction (if, switch..)
  33. 33. OCP not respected
  34. 34. OCP
  35. 35. Liskov Substitution Principle - LSP “objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.” if S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e. objects of type S may substitute objects of type T) without altering any of the desirable properties of that program (correctness, task performed, etc.) Similar to Design by Contract by Bertrand Meyer
  36. 36. LSP not respected
  37. 37. LSP respected
  38. 38. Interface segregation principle - ISP “many client-specific interfaces are better than one general-purpose interface” ● Client should not be forced to depend upon interfaces they do not use ● The number of members in the interface that are visible should be minimized ● Very large interface should be split into smaller ones ● Large classes should implement multiple small interface that group functions according to their purpose (SRP once again)
  39. 39. ISP not respected
  40. 40. ISP respected
  41. 41. Dependency Inversion Principle - DIP When dependencies exist between classes, they should depend upon abstractions, such as interfaces, rather than referencing classes directly ● High-level modules should not depend on low-level modules. ○ Both should depend on abstractions. ● Abstractions should not depend upon details. ○ Details should depend upon abstractions. Often met with the of dependency injection. Surely breaking the principle when you have difficulty to test or change the behavior of your code
  42. 42. DIP not respected
  43. 43. DIP respected
  44. 44. Domain Driven Design ● Ubiquitous language ● Value object / Entity / Aggregate ● Repository / Service ● Bounded context ● Anti-corruption layer Hexagonal (Onion / Clean) Architecture
  45. 45. There are only two hard things in Computer Science: cache invalidation and naming things. -- Phil Karlton Ubiquitous Language
  46. 46. To go farther : leaving the layered architecture Classic drawbacks: ● typically assumes that an application communicates with only two external systems : the client and the database. ● technical elements (like persistence layer framework) creeps into the domain logic ● difficult to test domain logic without involving the data layer
  47. 47. Hexagonal Architecture Principles: ● the domain model does not depend on any other layer; all other layers depend on the domain model. ● abstract external systems and APIs with a Facade. A facade is a simplified view of the external system and an interface written in terms of domain objects ● The domain logic will only deal with the facade, and can be tested thoroughly using stubbed and mocked versions of that interface.
  48. 48. Time for Code Kata / Coding Dojo
  49. 49. Kata - refactoring Trip Service Kata The objective is to write tests and refactor the given legacy code.
  50. 50. Birthday greetings Kata with hexagonal architecture Business need: ● Loads a set of employee records from a flat file ● Sends a greetings email to all employees whose birthday is today Example of email: Subject: Happy birthday! Body : Happy birthday, dear John! Example of flat file: last_name, first_name, date_of_birth, email Doe, John, 1982/10/08, Ann, Mary, 1975/09/11, public static void main(String[] args) { ... BirthdayService birthdayService = new BirthdayService( employeeRepository, emailService ); birthdayService.sendGreetings(today()); }
  51. 51. Refactoring
  52. 52. Refactoring smells - Duplicated code - Long Method - Large Class - Long Parameter List - Divergent Change - Parallel Inheritance Hierarchies - Lazy Class - Shotgun Surgery - Feature Envy - Data Clumps - Primitive Obsession - Switch Statements
  53. 53. Refactoring smells - Specualitve Generality - Temporary Field - Message Chains - Middle Man - Inapropriate Intimacy - Alternative Classes with Different Interfaces - Incomplete Library Class - Data Class - Refused Request - Comments
  54. 54. Refactoring ….. - Composing Methods - Moving Features between objects - Simplifying Conditional Expression - Making Method Calls Simpler - Organizing Data - Dealing with Generalization