The document discusses principles of craftsmanship in software development, including clean code, test-driven development, domain-driven design, and refactoring. It emphasizes writing code with quality, simplicity, shared ownership, and professionalism. It provides examples of unit testing principles like FAST and describes techniques like the TDD loop and code katas/dojos. It also explains SOLID principles for object-oriented design such as single responsibility, open/closed, Liskov substitution, and others. Finally, it discusses refactoring code smells and techniques for improving code quality through refactoring.

1. Yannick Grenzinger
@ygrenzinger

2. Some history

3. Typical flow of development (before)

5. Scrum

6. What is craft ?

11. But really for me as a developper,
why craft is important ?

12. Working software is not enough

13. You don’t like code without it

14. “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

16. 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."

17. Test First

18. Unit tests and TDD

19. Why ?

20. Pyramid of tests

21. 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

22. 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!)

23. 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

24. 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

26. Double loop

27. Kata “classic” lists
http://codingdojo.org/
https://leanpub.com/codingdojohandbook

28. 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

29. 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

30. 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.

31. 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"

32. Clean Code

33. 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

34. 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

35. SOLID principles
● Single Responsibility
● Open / Closed
● Liskov Substitution
● Interface Segregation
● Dependency Inversion

37. 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)

38. SRP not respected

39. SRP respected

41. 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..)

42. OCP not respected

43. OCP

45. 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

46. LSP not respected

47. LSP respected

49. 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)

50. ISP not respected

51. ISP respected

53. 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

54. DIP not respected

55. DIP respected

56. Domain Driven Design
● Ubiquitous language
● Value object / Entity / Aggregate
● Repository / Service
● Bounded context
● Anti-corruption layer
Hexagonal (Onion / Clean) Architecture

57. There are only two hard things in Computer Science: cache invalidation and naming
things.
-- Phil Karlton
Ubiquitous Language

58. 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

59. 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.

60. Time for Code Kata / Coding Dojo

61. Kata - refactoring
Trip Service Kata
The objective is to write tests and refactor the given legacy code.
https://github.com/sandromancuso/trip-service-kata

62. 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, john.doe@foobar.com
Ann, Mary, 1975/09/11, mary.ann@foobar.com
public static void main(String[] args) {
...
BirthdayService birthdayService = new BirthdayService(
employeeRepository, emailService
);
birthdayService.sendGreetings(today());
}

63. Refactoring

64. 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

65. 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

66. Refactoring …..
- Composing Methods
- Moving Features between objects
- Simplifying Conditional Expression
- Making Method Calls Simpler
- Organizing Data
- Dealing with Generalization