Software Craftmanship - Cours Polytech

Yannick Grenzinger
@ygrenzinger

Typical ﬂow of development (before)

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

Working software is not enough

You don’t like code without it

“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 Eﬀectively with Legacy Code

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

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

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
ﬁrst!)

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

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

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

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

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

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.

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"

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

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

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

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)

Open / Closed Principle - OCP
“software entities … should be open for extension, but closed for modiﬁcation” -
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..)

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

Interface segregation principle - ISP
“many client-speciﬁc 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)

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 diﬃculty to test or change the behavior
of your code

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

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

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

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.

Time for Code Kata / Coding Dojo

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

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());
}

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

Refactoring smells
- Specualitve Generality
- Temporary Field
- Message Chains
- Middle Man
- Inapropriate Intimacy
- Alternative Classes with Diﬀerent Interfaces
- Incomplete Library Class
- Data Class
- Refused Request
- Comments

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

Software Craftmanship - Cours Polytech

More Related Content

Similar to Software Craftmanship - Cours Polytech (20)

More from yannick grenzinger (18)

Recently uploaded (20)

Software Craftmanship - Cours Polytech