Vous n'écrivez pas ce code pour vous.
Quelqu'un en héritera
au prochain sprint.
5 équipes traitent le même sujet, chacune dans son dépôt. À la fin du sprint, une base de code est retenue et devient la base commune : tout le monde repart de celle-là, et les 4 autres s'arrêtent là. Au prochain sprint, vous avez donc 4 chances sur 5 de continuer sur du code écrit par une autre équipe. Toute la consigne découle de là.
« Voudrais-je hériter de cette base ? »
C'est ce qui arrive littéralement au sprint suivant.
Une base de code
Votre progression vit dans votre livret, et elle vous appartient.
Autorisés, s'ils sont écrits
Une décision assumée et justifiée vaut autant qu'une règle suivie.
Autorisés, sans réserve
On évalue ce que vous en faites et ce que vous savez défendre.
À connaître avant les détails
2 règles gouvernent tout le reste.
On évalue une base de code. La grille de revue s'applique à un dépôt, et le rapport d'analyse parle de fichiers et de lignes, sans nom d'auteur. Votre progression individuelle vit dans votre livret.
Un écart écrit vaut autant qu'une règle suivie. Chaque principe de cette page admet un écart. Dupliquer du code, contourner une abstraction ou écrire une fonction longue peuvent être le bon choix. Ce qui sépare une décision d'une négligence, c'est que la décision soit écrite quelque part et que vous puissiez la défendre.
Le sujet
De qui vous prenez vos consignes.
Le sujet vient d'un besoin réel, apporté par l'entreprise marraine de la promotion. Le formateur est l'unique interlocuteur de l'entreprise : c'est lui qui porte le besoin, qui l'explique et qui l'arbitre. Si une direction technique vous est suggérée, le formateur recadre sur place : c'est lui qui porte la règle. Chaque semaine, votre équipe a une revue de code formative avec lui : ses remarques restent dans GitHub, en commentaires de pull request ou en issues.
Elle est invitée à vos soutenances de sprint comme à la soutenance finale, ainsi qu'à la démonstration des 5 bases qui ouvre le j9. Elle y pose ses questions directement. Les échanges avec elle ne comptent pas dans votre évaluation, et elle ne vous donne aucune consigne : le besoin est porté par le formateur, qui conduit la séance.
Le dépôt
Ce qui est déjà en place, et où vont les choses.
Vous partez d'un dépôt modèle : environnement installé, configuration en place, emplacement des fichiers fixé. Les 5 bases suivent la même structure.
La CI est câblée
- Linter, formatter et analyse statique tournent à chaque poussée.
- Votre base est évaluée dans l'état où elle est, CI rouge comprise. L'écart pèse sur le rang.
Les tests ont leur place
tests/unit/,tests/integration/,tests/e2e/.- Vous écrivez ce que vous jugez utile, quand vous le jugez utile.
- On vous demande seulement de le ranger là.
Les décisions ont leur place
docs/adr/pour les décisions structurantes.- Un commentaire préfixé
# pourquoi :pour les choix locaux. - Vos justifications se cherchent là, et seulement là.
Fin de sprint
Ce qu'on attend d'une base rendue.
- La CI est verte.
- Le projet démarre en une commande, sur une machine qui ne connaît rien de votre contexte.
- Le README dit quoi faire, dans l'ordre, sans supposer qu'on vous a parlé.
- Les tests couvrent ce qui porte de la logique métier.
- Les décisions structurelles du sprint ont leur ADR.
- Le dépôt, historique compris, est exempt de secret et de donnée réelle. Chaque TODO y est justifié.
Le geste nouveau
Écrire pourquoi.
Écrire pourquoi est probablement le seul geste nouveau pour la plupart d'entre vous. Un ADR est un fichier court, numéroté, qui fige une décision structurante. Vous en écrivez autant que vous avez pris de décisions qui engagent la suite.
# 0004 - Un repository pour l'accès aux commandes
## Contexte
Les requêtes SQL sur les commandes étaient écrites dans les routes HTTP,
ce qui rendait le métier intestable sans base de données.
## Options
1. Laisser en l'état, plus rapide à écrire.
2. Un repository injecté, testable avec un double.
3. Un ORM complet, plus puissant mais plus lourd pour ce périmètre.
## Décision
Option 2.
## Conséquences
Le métier devient testable sans base de données. Un fichier de plus par entité.
Si un jour on a besoin de requêtes complexes, il faudra rouvrir ce choix.Un ADR vaut par ses options écartées et ses conséquences.
Pour les choix locaux, 2 lignes suffisent, à l'endroit du choix :
# pourquoi : duplication assumée. Factoriser avec le calcul de devis
# créerait un couplage entre facturation et commercial pour 3 lignes.Une duplication accompagnée de ces 2 lignes est un choix. La même sans rien est un oubli. L'agent de revue ne juge pas votre intention : il constate le fait et regarde si l'intention est écrite. C'est le formateur qui tranche ensuite, et vous pouvez encore le convaincre à l'oral.
Les tests
Quoi tester, et à quel niveau.
Les tests permettent à l'équipe suivante de modifier votre code sans le craindre.
- L'essentiel porte sur la logique métier, testée sans base de données ni réseau : c'est ce qui casse le plus souvent et ce qui se teste le plus vite.
- Les tests d'intégration vérifient les contrats : une route répond ce qu'elle annonce, une requête écrit ce qu'elle prétend.
- Quelques tests bout en bout, sur les parcours qui comptent.
- Laissez de côté les accesseurs, les objets de transport et le framework lui-même.
- Un test sans assertion utile donne une fausse assurance et gonfle une couverture qui perd alors son sens.
- Partez des règles du projet : une règle, un test. Le pourcentage de couverture indique seulement quelles lignes les tests exécutent. L'utilité d'un test tient à ce qu'il vérifie.
Duplication, abstraction, structure
3 pièges, et ils vont dans les 2 sens.
- Sur-factoriser coûte autant que dupliquer : une interface inutile ou une couche d'abstraction créée pour un besoin encore hypothétique donnent du travail en plus à l'équipe qui hérite, sans contrepartie.
- Dupliquer est parfois le bon choix, notamment pour isoler 2 domaines qui évoluent séparément. Écrivez pourquoi.
- Séparer les responsabilités vaut surtout à la frontière entre le métier et le reste : ce qui décide doit rester indépendant de ce qui affiche et de ce qui stocke.
Les outils d'IA
Autorisés. Et voilà ce que ça implique.
Sans restriction ni déclaration. Piloter ces outils fait partie du métier. L'autorisation a 3 conséquences, à prendre au sérieux.
Vous êtes responsable
de ce que vous livrez
Le code généré est votre code. S'il est faux, c'est votre erreur.
On évalue l'usage
et ce que vous savez en dire
Du code que vous ne savez pas expliquer vaut zéro à la soutenance, quelle que soit sa qualité apparente.
Relire est une compétence
probablement la plus utile
Traitez une sortie d'agent comme une contribution d'un inconnu : lisez-la avant de l'accepter.
L'agent de revue passe aussi sur votre base à chaque fin de sprint. Vous pouvez lancer l'analyse vous-même avant de rendre : la grille est publiée et les outils sont autorisés.
La publication
Votre code sera public.
Pendant le sprint, votre dépôt est privé : les 5 équipes travaillent chacune de leur côté. Au j9, une fois gelées, les 5 bases sont publiées en open source, sous licence Apache 2.0, avec leur historique complet. La publication précède la peer-review. Le détail des dépôts : branches, tags, et le cycle de vie de votre code sur les 11 semaines.
git commit -s. C'est cette signature qui porte la licence, commit par commit.-sLa configuration à faire au premier jour
- Créez un compte GitHub sous votre pseudonyme. Ce pseudonyme vous suivra au-delà de la promotion : choisissez-le comme vous choisiriez un nom professionnel.
- Dans
Settings › Emails, cochez « Keep my email addresses private » et « Block command line pushes that expose my email ». La seconde fait refuser par GitHub tout envoi qui exposerait votre adresse. Relevez au passage votre adresse@users.noreply.github.com. - Configurez git dans le dépôt de l'équipe :
git config user.name "votre-pseudonyme" git config user.email "ID+pseudonyme@users.noreply.github.com" git config format.signOff true - Vérifiez avant le premier envoi :
git log -1 --format='%an %ae%n%b'doit afficher votre pseudonyme, l'adressenoreply, et la ligneSigned-off-by. - Le formateur contrôle ces 3 points avant le premier envoi de chaque équipe.
Vous repartez avec une preuve vérifiable : un lien vers vos commits montre ce que vous avez écrit, quand, et ce que vous avez relu chez les autres. Le dépôt reste public sous licence Apache 2.0, et vos commits sont signés.
Sécurité
3 failles pèsent lourd, et se corrigent.
Une entrée utilisateur qui devient du code (requête construite par concaténation, commande shell assemblée à la main). Un secret en clair dans le dépôt ou dans l'historique. Une authentification contournable.
Le dépôt est publié à la fin du sprint, historique compris. Un secret commité déclenche donc une procédure de rotation : vous le signalez immédiatement, la clé est révoquée et remplacée, et le fait est consigné dans la fiche de passation. Avant la publication, la valeur est effacée de l'historique et remplacée par une mention du retrait : l'effacement garde tous les commits, avec leurs messages, leurs auteurs et leurs dates. Les 3 failles mettent le critère 07 de la grille à zéro, soit 4 points perdus, et le formateur peut en retirer 5 de plus par faille, en motivant sa décision par écrit, selon la gravité de la faille et selon qu'elle était évitable. Si votre base est la meilleure, elle devient quand même la base commune, et sa correction ouvre le sprint suivant. Le reste de l'hygiène (image de base non figée, dépendance obsolète) est un signal noté. Le formateur vérifie chaque signalement automatique avant toute décision.
L'évaluation
100 points, 3 notes qui mesurent chacune une chose différente.
Les 3 notes sont communiquées le j10 à 15h30, et le classement des 5 bases est annoncé le j1 suivant à 11h00. À total égal, le regard des pairs départage, puis la qualité de la base, puis la soutenance. Si tout reste égal, le formateur tranche par écrit.
Le droit à l'erreur
Vous pouvez vous tromper.
Vous pouvez choisir une option qui se révèle mauvaise et le dire, ne pas savoir, poser une question qu'on juge évidente. Vous pouvez rendre une base imparfaite en expliquant ce que vous auriez fait avec une semaine de plus. Tout cela fait partie du parcours.
Ce qui se paie, c'est de ne pas écrire pourquoi, de rendre du code que vous ne comprenez pas, et de laisser à l'équipe suivante un dépôt qu'elle n'arrive pas à faire tourner.
La grille de revue, le barème de l'oral et le guide de peer-review sont publiés : livret d'accueil · livret de progression · programme · positionnement · grille · soutenance · peer-review · dépôts · assiduité · épreuves · encadrement · règlement intérieur