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
- 421