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.
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
15.
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."
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
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"
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
36.
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)
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..)
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
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)
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
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.
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());
}