Poste
Développeur logiciel
Combien de temps faut-il à une nouvelle personne de l'équipe pour faire son premier changement qui compte ? Ce chiffre en dit plus sur votre code et votre documentation que n'importe quelle métrique de qualité.
Entretien préalable
Quatre questions par lesquelles nous commencerions
Combien de temps faut-il à une nouvelle personne pour faire son premier changement ?
Si c'est des semaines, vous payez le coût d'intégration à chaque rotation, et la rotation dans ce métier est un fait.
Qu'est-ce que vous repoussez en premier quand une échéance approche ?
En général les tests et la mise en ordre du code, c'est-à-dire ce qui devient la dette que rembourse le trimestre suivant.
Où va la connaissance de pourquoi quelque chose a été fait ainsi ?
Si elle va dans une conversation de revue de code, dans six mois personne ne saura si c'était un choix ou un accident.
Quel type de tâche revient le plus souvent ?
En général trois ou quatre motifs, et en général personne ne les a comptés.
Nous prenons le travail répétitif, vous gardez la conception et le jugement
Comprendre le contexte du code, ébaucher les changements répétitifs, préparer les tests et une première passe de revue peuvent être retirés du bureau. Les décisions de conception et le jugement final sur le code restent à une personne.
- Le contexte arrive plus vite qu'en lisant. - Ce que fait ce module, qui l'a changé et quels changements lui sont liés, avant que le développeur ne commence à lire ligne à ligne.
- La revue commence par ce que le linter et l'intégration continue ne détectent pas. - Le formatage et les tests, vous les tenez presque certainement depuis longtemps. Ici c'est la couche au-dessus : si le changement touche des endroits que l'auteur a pu ne pas voir et s'il reprend une solution écartée il y a six mois.
- La dette se voit au lieu de se ressentir. - Les endroits les plus souvent modifiés et ceux de plus forte complexité sont signalés, donc la conversation sur le refactoring a un fondement.
Périmètre
Ce qui peut être retiré d'une équipe de développement
Dix-neuf tâches à titre d'exemple. Chacune a un point de validation humaine. Ci-dessous une sélection ; le périmètre, nous l'ajustons à votre stack et à votre processus.
Compréhension du code et de son contexte
- Une description de ce que fait un module, à partir du code (vérification : le développeur)
- Signalement des endroits liés au fragment modifié
- L'historique des changements dans la zone avec leurs motifs
- Signalement de la documentation couvrant la zone
Écriture du changement
- Une ébauche de changement pour les motifs répétitifs (jugement et correction : le développeur)
- Une proposition de tests pour le changement écrit
- Signalement des endroits à mettre à jour après le changement
- Un signal quand un changement rompt les conventions convenues
Revue de code
- Une première passe de revue avant la revue humaine
- Signalement des tests manquants
- Signalement des changements qui touchent des endroits liés que l'auteur pouvait ignorer
- Les changements à revoir ordonnés par risque (décision : le relecteur)
- Un rappel sur une revue en attente
Tests et livraison
- Une proposition de cas que les tests existants ne couvrent pas
- Signalement des tests qui ont cessé de passer et du motif du changement de comportement
- Lier le changement à la tâche et à la livraison
Dette technique
- Signalement des zones les plus souvent modifiées
- Un récapitulatif des endroits de plus forte complexité
- Lier les anomalies de production aux zones du code
Une journée de travail
Aujourd'hui
- Avant un changement, vous lisez le module pour comprendre seulement ce qu'il fait
- Vous trouvez les endroits liés en cherchant et grâce à la mémoire de l'équipe
- Vous écrivez le travail répétitif à la main, bien qu'il ait chaque fois la même allure
- Le relecteur déduit lui-même ce que ce changement touche d'autre
- Une revue attend un jour ou deux, parce que personne ne sait qu'elle attend
- Vous parlez de dette technique à la rétrospective, sans données
Avec l'assistance de l'IA
- Vous avez la description du module et les endroits liés avant de lire le code
- Un changement répétitif a une ébauche, vous le jugez et le corrigez
- Les tests du changement ont une proposition
- Les endroits liés sont signalés avec le changement au lieu d'être cherchés
- Une revue en attente se rappelle d'elle-même
- La dette technique est signalée avec des chiffres, pas avec une impression
- Délai jusqu'à un premier changement
une nouvelle personne entre plus tôt dans le code
le contexte d'un module est accessible sans tout lire
- Temps d'attente d'une revue
les changements ne traînent pas dans la file sans qu'on les voie
des rappels et un ordre fondé sur le risque
- Qualité de la revue
le relecteur voit la portée du changement et non seulement le diff
les endroits liés et l'historique des décisions accompagnent le changement
- Une dette visible
la conversation sur le refactoring s'appuie sur des chiffres
les zones souvent modifiées et les zones complexes sont signalées
Nous commençons par le contexte et la revue, parce que c'est le moins risqué et le plus vite ressenti.
- Étape 1
Contexte du code et relations
Descriptions de modules, historique des changements, endroits liés.
- Étape 2
Première passe de revue et tests avant la revue humaine
Conventions, tests manquants, erreurs évidentes avant l'œil d'une personne.
- Étape 3
Ébauches de changements répétitifs
Seulement les motifs qui se répètent vraiment, et toujours avec le jugement du développeur.
- Étape 4
Une dette visible
Les zones les plus souvent modifiées, liées aux anomalies de production. En dernier, parce que cela exige de l'historique.
Questions fréquentes
Les questions qui reviennent à la première réunion
Et le code que nous n'avons pas le droit d'envoyer où que ce soit ?
C'est une condition fréquente et elle se règle au stade de l'architecture, pas dans le contenu. Les solutions qui tournent dans votre propre infrastructure sont réelles ; si elles ne le sont pas, le périmètre se réduit à ce qui se fait sans envoyer de code à l'extérieur. Cette conversation vaut la peine d'être tenue avant plutôt qu'après.
C'est la question que se pose aujourd'hui tout le marché : l'IA remplacera-t-elle les programmeurs ?
La réponse honnête : pas dans le périmètre décrit ici, et nous ne prétendons pas avoir de réponse à la question entière. Ce que nous proposons concerne le contexte du code, les motifs répétitifs et la première passe de revue, c'est-à-dire de toute façon le travail qu'un développeur trouve le moins intéressant. Les décisions de conception, le jugement des arbitrages et la responsabilité de ce qui arrive en production restent à l'équipe. Si nous prenons plus que cela, c'est vous qui y perdez et non nous, et c'est pourquoi la limite vaut la peine d'être fixée avec l'équipe plutôt qu'à sa place.
Cela relève-t-il du règlement sur l'IA ?
Produire du logiciel n'est pas un usage à haut risque. Le seul point qui demande de la prudence, c'est que les données sur les changements de code ne servent pas à comparer la productivité de développeurs précis : nous tenons les récapitulatifs par zone de code et non par auteur.
Une question qui ne figure pas ici ? Réservez un appel
Étape suivante
Combien de temps votre équipe passe-t-elle à lire du code avant de le modifier ?
Nous vous montrerons à quoi ressemble le travail d'une équipe quand le contexte arrive plus tôt et que la revue de code commence par les décisions de conception.