Le module R2.03 en un coup d'œil

Apprendre à produire du code propre, testé, relu et maintenable. Passer de "ça marche sur ma machine" à un vrai réflexe professionnel.

Organisation du module

Évaluation

Trois notes, un objectif : vérifier que vous maîtrisez des gestes de métier, pas juste que votre code tourne.

Environnement de travail

Tout le module se fait sur GitHub Codespaces dans votre navigateur sans installation :

Qu'est-ce que l'artisanat logiciel ?

Un artisan menuisier livre une table bien finie, robuste, belle, facile à réparer. Un artisan logiciel livre du code qui doit être :

Le manifeste de l'artisanat logiciel (2009)

✊ Snowbird, Utah, décembre 2008, en écho au Manifeste Agile de 2001, 4 principes, toujours sur le même modèle : non seulement X, mais aussi Y.

Pourquoi c'est important : le coût des bugs

Plus un bug est détecté tard, plus il coûte cher à corriger. Ordre de grandeur (Boehm, 1981) :

La dette technique

Métaphore de Ward Cunningham (1992) : écrire du code sale pour livrer vite, c'est comme emprunter de l'argent. Ça aide à court terme, mais il faut rembourser, avec intérêts.

Les 4 gestes de l'artisan du logiciel

Derrière chaque pilier du module, un geste métier que pratique l'artisan, pas juste un outil technique.

Pourquoi ce module compte tout de suite

Compétences BUT visées

Trois apprentissages critiques du PN BUT Informatique 2022 (annexe 15) sont couverts ici.

Ce que vous savez déjà (plus ou moins bien)

Au S1, vous avez utilisé Git. Vérifiez avec moi :

Rappel express : le modèle Git

Il vous suffit de retenir 3 concepts pour suivre le reste du cours :

Pourquoi un bon message de commit ?

Le message que vous écrivez aujourd'hui sera relu par quelqu'un d'autre (ou vous-même) dans 6 mois, pour comprendre pourquoi telle ligne a été écrite.

wip
fix
trucs
ca marche enfin putain
update file

feat(auth): ajoute login via OAuth Google
fix(cart): corrige le total quand la remise est 0
docs(readme): detaille l'installation locale
refactor(facture): extrait appliquerTVA

Le format Conventional Commits

Un standard universel pour structurer vos messages et rendre votre historique lisible par tous.

GitHub Flow : le workflow en 4 étapes

Le workflow standard en équipe, proposé par Scott Chacon (GitHub, 2011). Simple : une seule branche de référence (main) et des branches éphémères par fonctionnalité.

Pull Request : une conversation

Une PR n'est pas un formulaire administratif. C'est une invitation à discuter du code que vous proposez d'intégrer à la branche main.

Comment faire une bonne review ?

Reviewer, ce n'est pas dire "oui". C'est lire le code avec les yeux d'un collègue dans 6 mois, et mettre son nom en face de ce qui partira en prod.

Review automatique par Copilot

Dans vos Codespaces, Copilot Code Review peut commenter automatiquement une PR ouverte. Utile, mais ne remplace pas une vraie revue.

git merge : avant la fusion

Vos commits sur la branche ma-feature sont prêts à être partagés. Voici la première façon de les intégrer à la branche main : git merge.

git merge : après la fusion

Vos commits sur la branche ma-feature sont prêts à être partagés. Voici la première façon de les intégrer à la branche main : git merge. Après cette opération, un nouveau commit de merge fait la jointure entre les deux branches.

git rebase : avant le rebase

Vos commits sur la branche ma-feature sont prêts à être partagés. Voici la seconde façon de les intégrer à la branche main : git rebase.

git rebase : après le rebase

Vos commits sur la branche ma-feature sont prêts à être partagés. Voici la seconde façon de les intégrer à la branche main : git rebase. Le rebase rejoue les commits D et E sur la pointe de main. D et E deviennent D' et E' : même contenu, mais nouveaux commits avec de nouveaux SHA.

La règle d'or pour choisir entre merge et rebase

Rebase interactif : nettoyer l'historique

git rebase -i HEAD~3 ouvre un éditeur qui liste les 3 derniers commits, un par ligne, avec une action modifiable devant chacun.

pick a1b2c3 wip
pick d4e5f6 maj
pick g7h8i9 fix typo
# Rebase ...
# p, pick   = use commit
# r, reword = edit message
# s, squash = meld into previous
# f, fixup  = like squash, no msg
# d, drop   = remove commit

Rebase interactif : exemple concret

Cinq commits de travail accumulés au fil de la journée, à fusionner en un seul commit propre prêt pour la PR.

a1b2c3 wip
d4e5f6 maj
g7h8i9 fix typo
h1j2k3 oh j'avais oublié un test
m4n5o6 deuxième essai

x7y8z9 feat(auth): ajoute login OAuth Google

cherry-pick : avant

Sur une branche expérimentale exp, le commit D contient un correctif utile. Vous voulez juste ce commit-là sur main, sans embarquer C ni E.

Le besoin :

• Récupérer uniquement D sur main
• Laisser C et E sur exp (encore en cours)
• Sans merge (qui rapatrierait tout)
• Sans rebase (qui réécrirait exp)

cherry-pick : après

cherry-pick copie le commit D sur la pointe de main. Il devient D' : même contenu, mais nouveau commit avec un nouveau SHA.

git checkout main
git cherry-pick D

exp reste intacte : C, D et E sont toujours là pour continuer la branche expérimentale plus tard.

Outil de secours : reflog

Vous tapez git reset --hard HEAD~5 et réalisez que vous venez d'effacer 5 commits. Pas de panique : Git garde une mémoire locale de tous vos déplacements.

$ git reflog
a1b2c3 HEAD@{0}: reset: moving to HEAD~5
g7h8i9 HEAD@{1}: commit: feat: ajoute X  ← ici !
d4e5f6 HEAD@{2}: commit: wip
...

$ git reset --hard g7h8i9
HEAD is now at g7h8i9 feat: ajoute X
✅ Vos commits sont récupérés.

Commandes destructrices et leurs alternatives

Certaines commandes Git détruisent du travail sans demander confirmation. Pour chacune, il existe une variante équivalente qui refuse d'écraser silencieusement.

Démo live : rebase d'une branche sur main

Cycle complet en direct : brancher, commiter, rebaser, pousser sans casser le travail des autres. Posez vos questions pendant la démo.

De l'historique propre au code qui tient

Git assure la trace propre de votre travail. Mais une belle histoire ne garantit pas que le code actuel marche. Il vous faut l'autre moitié du métier.

Le problème du code "ça marche sur ma machine"

Trois situations qu'on a toutes et tous vécues, et qui ont une seule cause profonde.

Qu'est-ce qu'un test automatisé ?

Un test automatisé, c'est du code qui exécute d'autres bouts de code et vérifie automatiquement le résultat attendu. Pas de clic manuel, pas de vérif à l'œil.

Le test unitaire : zoomer sur une seule unité

Un test unitaire vérifie une seule unité de code (une méthode, ou une classe), isolée du reste de l'application : pas de base de données, pas de réseau, pas de fichiers.

À quoi ressemble un test JUnit ?

Un test JUnit, c'est juste une méthode Java qui en appelle une autre et vérifie le résultat. Trois phases, toujours les mêmes : Given · When · Then.

@Test
void additionne_deux_et_trois_retourne_cinq() {
    // Given : on a une calculatrice
    Calculatrice calc = new Calculatrice();
    // When : on additionne 2 et 3
    int resultat = calc.additionne(2, 3);
    // Then : on attend 5
    assertThat(resultat).isEqualTo(5);
}

Lancer ses tests : le feedback loop

Vous lancez vos tests d'une commande ou d'un clic, et JUnit vous répond en quelques secondes : tout vert, ou rouge avec le détail précis de l'échec.

$ ./mvnw test

[INFO] Tests run: 12, Failures: 0
[INFO] BUILD SUCCESS

[ERROR] additionne_deux_et_trois...
  expected: 5
   but was: 6
[ERROR] BUILD FAILURE

La suite de tests : votre filet de sécurité

Un test isolé, c'est un seul point d'ancrage. Ce qui vous tient vraiment, c'est la suite qui s'accumule au fil du projet, et qui se relance en entier à chaque modification.

La CI : le filet qui se déploie automatiquement

À chaque git push, GitHub Actions relance votre suite de tests sans même que vous demandiez. C'est l'Intégration Continue (CI).

Qu'est-ce qu'une bonne suite de tests ?

Toutes les suites de tests ne se valent pas. Une bonne suite tient sur quatre propriétés, et chacune compte autant que les autres.

Le piège de tester APRÈS avoir codé

Quand le code marche déjà, écrire des tests devient fastidieux. Et on ne sait pas quand s'arrêter, parce qu'aucun test n'est nécessaire par construction. Deux dérives symétriques s'installent.

TDD : l'idée contre-intuitive

Le D de TDD, c'est Driven, dirigé. Un test à la fois commande ce que vous codez ensuite. La conception émerge pas à pas, elle n'est pas planifiée à l'avance.

Le cycle RED - GREEN - REFACTOR

Trois étapes, dans cet ordre, pour chaque petit comportement à ajouter. À la fin du tour, on reprend avec le test suivant.

Les 3 stratégies de Kent Beck

Pour passer du RED au GREEN, trois approches au choix selon la complexité du test à faire passer.

// saluer("Alice") == "Hello, Alice!"
return "Hello, Alice!";

// saluer("Alice"), saluer("Bob")
return "Hello, " + nom + "!";

// additionner(2, 3) == 5
return a + b;

Baby steps : petits pas, toujours

La règle d'or du TDD : un test = un petit pas de code = un point de contrôle. Si vous modifiez 30 lignes entre deux exécutions de tests, vous codez à l'ancienne, en priant.

Kata live : HelloWorld en TDD

On va écrire ensemble une méthode saluer(String nom). Quatre tests fournis, activés un par un, dans l'ordre. Vous observez, je code.

Copilot Chat : votre tuteur, pas votre code-monkey

Sur les TP de R2.03, Copilot est configuré comme tuteur TDD. Il aide à raisonner, mais refuse de court-circuiter la démarche.