SOFTWARE-CRAFTING

  • VOUS ÊTES QUI ?

  • VOUS VOULEZ QUOI ?

  • COMMENT ALLEZ-VOUS ?

Solutions to most of tech problems :

- slow down

- sit down and talk to people

- try things

 - rest, go home

FONCTIONNEMENT PRATIQUE :

  • La journée (9h-17h)
  • Pauses
  • de la pratique
  • binôme / Mob
  • Pas obligé de finir
  • A la carte. On est agile

PROGRAMME :

  • Agilité

  • Specs

  • Tests, TDD, ATDD

  • Qualité, Clean-Code

  • Pair/mob, review

  • Legacy, Refactoring

AGILE

TL;DR

But

  • Avoir le bon produit

  • Le livrer rapidement

Moyens

  • Itérations

  • Auto-organisation

EXTREME PROGRAMMING

XP VALUES:

  • Communication

  • Simplicity

  • Feedback

  • Courage

  • Respect

XP PRACTICES

XP PRACTICES

SOFTWARE-CRAFTSMANSHIP

NAMING

Is Craftsmanship inclusive? and Crafting? and Craft?

Craftsman, craftswoman, craftsperson, crafter

SOFTWARE-CRAFTING

PRACTICES

Tests, TDD, Clean-Code, Naming, Comments, Communication, Code-review, Pair-programing, Mob-programing, Simple-Design, SOLID, Iteration, Baby-steps, Refactoring, Mentoring, Collective ownership, Self-organization, Continuous Integration, Continuous Delivery

...

SPECS

SPECS

IMPRÉCISES

Rédigez un cahier des charges pour écrire des nombres en lettres

 

pluriel de "vingt" et "cent".

"et-un" ou "-un" ?

Facile != Simple

SPECS

Le besoin peut évoluer.

Le besoin va évoluer.

"Si votre besoin n'évolue plus, c'est que vos utilisateurs sont morts."

SPECS

ITÉRATIONS

  • peu de risques
  • possibilités de changer
  • adaptation en fonction des retours d'utilisations
  • obligé de découper en tout petits incréments
  • plus le temps passé à écrire les specs est court, plus on accepte de les changer

SPECS

ITÉRATIONS

  • peu de risques
  • possibilités de changer
  • adaptation en fonction des retours d'utilisations
  • obligé de découper en tout petits incréments
  • plus le temps passé à écrire les specs est court, plus on accepte de les changer

SPECS

USER STORY

SPECS

SMART :

  • Specific
  • Mesurable
  • Achievable
  • Relevant
  • Time Bound

Pas la peine d'essayer de réaliser si ce n'est pas possible.

SPECS

6 D

  • Désirable
  • Démontrable
  • Découpée
  • Dérisquée
  • Définition de Fini
  • Discutée (ou Débattue)

SPECS

PROBLÈMES :

Ce qui est implementé n'est que ce que les devs ont compris
On fini par livrer un logiciel qui "marche" mais qui n'est pas utilisable.
Soit specs et tests sont redondant (donc inutiles)
Soit specs et tests sont incohérents (donc il faut recommencer)
Les "données" utilisées ne correspondent pas du tout à des cas d'utilisations
(type de données, volume, contenu, temps ...)

SPECS

Le PO dit "là, par exemple, si je veux faire ... ça ne marche pas" avec un cas réel d'utilisations

autant utiliser les exemples dès le début !

SPECS

Calculatrice Lorsque je saisis 30, j’appuie sur le bouton +, je saisis 45, j’appuie sur le bouton égal, alors j’obtiens 75.

Orthodromie La distance orthodromique entre Paris (48°51’N – 2°21’E) et Montpellier (43°36’N – 3°53’E) est de 595 kms.

Calcul d’agios Sur le 4e trimestre 2012, un compte est débiteur de 451€ du 13/11 au 28/11 et de 342 € du 08/12 au 27/12, avec un taux d’intérêt de 20% annuel. Les intérêts sur la période sont de 7,27 €

PAIR-PROGRAMMING

POURQUOI ?

  • éviter des bugs
  • apprendre la technique
  • apprendre le contexte métier
  • partager les normes de codage
  • propriété collective du code
  • obliger à verbaliser le problème et la solution
  • discuter des besoins avant de coder
  • augmenter la concentration
  • être une équipe, discuter avec des humains

PAIR-PROGRAMMING

TRES FATIGUANT

  • commencer petit (1-2h par jour)

  • faire des pauses régulières
  • Pomodoro
  • évitez les grands open-spaces
  • changez de binômes
  • faites tourner le clavier
  • toujours dans le respect de l'autre

PAIR-PROGRAMMING

MOB-PROGRAMMING

Pourquoi s'arrêter à 2 ?

CLEAN-CODE

CLEAN-CODE

"N'importe quel idiot peut écrire un code qu'un ordinateur peut comprendre. Les bons programmeurs écrivent du code que les humains peuvent comprendre."

"Mal nommer les choses, c'est ajouter au malheur du monde !"

"Il n'y a que deux choses difficiles en informatique :
- l'invalidation du cache,
- nommer les choses".

UTILISEZ DU VOCABULAIRE MÉTIER

 
public List<int[]> getFlg() {
  List<int[]> list1 = new ArrayList<int[]>();
  for (int[] x : theList ) {
    if (x[0] == 4)
      list1.add(x);
  }

  return list1;
}
public List<Cell> getFlaggedCells() {
  List<Cell> flaggedCells = new ArrayList<Cell>();
  for (Cell cell : gameBoard ) {
    if (cell.isFlagged())
      flaggedCells.add(cell);
  }

  return flaggedCells;
}

SÉPAREZ LES NIVEAUX D'ABSTRACTION

public RGBColor readCurrentColor(BlinkLed led) {
    device.sendCommand(new ReadColorRequest(led));

    byte[] response = device.readResponse();

    int red = response[2] >= 0 ? response[2] : response[2] + 256;
    int green = response[3] >= 0 ? response[3] : response[3] + 256;
    int blue = response[4] >= 0 ? response[4] : response[4] + 256;
    return new RGBColor(red, green, blue);
}
public RGBColor readCurrentColor(BlinkLed led) {
    device.sendCommand(new ReadColorRequest(led));
    byte[] response = device.readResponse();
    return extractColor(response);
}
private RGBColor extractColor(byte[] response) {
    int red = convertToPositiveInt(response[2]);
    int green = convertToPositiveInt(response[3]);
    int blue = convertToPositiveInt(response[4]);
    return new RGBColor(red, green, blue);
}
private int convertToPositiveInt(byte byt) {
    return byt >= 0 ? byt : byt + 256;
}

SÉPAREZ LES NIVEAUX D'ABSTRACTION

  • Extract Method
  • Extract Variables
  • Extract Field
  • Donner des noms parlants
  • Une seule fonctionnalité par méthode

LOI DE DEMETER

a.getB().getC().doThings();

Pas bien ! 

Bien ! 

a.getB().doThings();

SOLID

  • S - Single-responsiblity principle
  • O - Open-closed principle
  • L - Liskov substitution principle
  • I - Interface segregation principle
  • D - Dependency Inversion Principle

S - SINGLE-RESPONSIBLITY PRINCIPLE

A class should have one and only one reason to change, meaning that a class should have only one job.

Evitez les Managers
Un manager fait un peu de tout mais mal, beaucoup de rien et embrouille tout le monde.

 

O - OPEN-CLOSED PRINCIPLE

Les objets ou entités devraient être ouverts à l'extension, mais fermés à la modification.

 

Penser héritage

L - LISKOV SUBSTITUTION PRINCIPLE

Let q(x) be a property provable about objects of x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T.
les objets d'un programme doivent pouvoir être remplacés par des instances de leurs sous-types sans altérer l'exactitude de ce programme.

 

I - INTERFACE SEGREGATION PRINCIPLE

Un client ne devrait jamais être obligé de mettre en œuvre une interface qu'il n'utilise pas ou les clients ne devraient pas être obligés de dépendre de méthodes qu'ils n'utilisent pas.

 

D - DEPENDENCY INVERSION PRINCIPLE

one should "depend upon abstractions, [not] concretions."
A. Les modules de haut niveau ne doivent pas dépendre des modules de bas niveau. Les deux devraient dépendre d'abstractions.
B. Les abstractions ne doivent pas dépendre de détails. Les détails doivent dépendre des abstractions.

 

CODE-REVIEW

 

  • Partir du principe que tout doit être questionné
  • Partir du principe qu'il y a toujours une explication

 

TOUJOURS RESPECTER LES AUTRES

Que l'on soit l'auteur-e du code ou la personne qui relit.

On critique le code, pas la personne

Hard with code, soft with human

CODE-REVIEW

 

  • POURQUOI ?

  • vérifier que la feature est bien réalisée
  • éviter des bugs
  • apprendre la technique
  • apprendre le métier
  • partager les normes de codage

l'apprentissage est dans les deux sens

CODE-REVIEW

 

  • En asynchrone, sur un outil de gestion de conf.

    En discutant au bureau de son/sa collègue.

    l'écrit peut être ambigue, surtout dans une langue qu'on maitrise mal.
    Attention aux tournures.
    Préférer les questions plutôt que les affirmations.

Software

By rodolphe

Software

  • 346