Modifications des limites de responsabilité provoquées par le Codex

Lorsque j’ai présenté Codex à l’équipe pour la première fois à grande échelle, la première bonne chose a été que j’étais enfin prêt à apporter quelques petits changements.

Une situation courante dans le passé était que tout le monde le savait clairement : ce code doit être refactorisé, ce script doit être testé et cette limite doit être enregistrée. Mais ils sont tous coincés dans la même réalité. Vous devez faire attention aux coûts pour commencer à écrire, et vous devez réviser après avoir écrit.

Le Codex réduit les « frictions pratiques ».

Les problèmes ont commencé à surgir à partir de ce jour.

Parce qu’à mesure que les frictions diminuent, les limites de la responsabilité évoluent également tranquillement.

En apparence, vous pensez peut-être que vous achetez des auteurs plus rapides, mais en réalité, vous achetez davantage de changements. Lorsqu’il y a trop de changements, le système a besoin d’une acceptation plus claire et de mécanismes de contrôle plus solides.

Dans le cas contraire, l’efficacité du Codex sera démontrée sous une autre forme : accidents en ligne, fatigue des révisions et retouches qui « semblent correctes mais instables » encore et encore.

Comment les choses sont-elles progressivement devenues “le critique est responsable”

Au cours de la première semaine après l’introduction du Codex, tout le monde l’a utilisé avec beaucoup de retenue.

-Écrire un widget

• Changer le nom d’un paragraphe
• Ajouter un jugement if

Ces changements, s’ils ne sont pas parfaits, comportent des risques limités.

À partir de la deuxième semaine, les changements se sont accentués.

Certaines personnes ont commencé à demander au Codex “d’organiser le code environnant en passant”, d’autres ont commencé à lui demander de “refactoriser ce module ensemble”, et certaines ont même remplacé une section entière de logique complexe par une version générée.

A ce stade, la phrase la plus courante est :

Regardez, tout le code est écrit et la logique est correcte.

Le problème est qu’il y a une substitution cachée dans cette phrase.

Dans le passé, l’auteur était principalement responsable de savoir si la logique était correcte ou non. L’auteur doit passer par une convergence complète lors de l’écriture : les raisons des changements, quelles sont les limites, que se passera-t-il en cas d’échec et comment revenir en arrière.

Le Codex aplatit le processus de convergence au milieu. L’auteur devient « celui qui revendique » et laisse la retenue au critique.

La limite de responsabilité commence donc à :

• L’auteur est responsable de faire converger les modifications jusqu’à ce qu’elles soient prêtes à être publiées.

est devenu :

• Les réviseurs sont responsables du filtrage des modifications jusqu’à ce qu’elles ne posent aucun problème.

Ce n’est pas une question morale, c’est une question mécanique.

Le mode de génération de code tend naturellement à « écrire d’abord une version » plutôt qu’à « réfléchir clairement aux limites d’abord ». Ce transfert de responsabilité se produit aussi longtemps que le processus ne rend pas les limites explicites.

Souvent, le prix sera payé immédiatement à trois endroits

1) La revue devient « archéologie »

Dans le passé, la critique examinait les choix de l’auteur :

• Utilisez-le pour réaliser
• Divisé en ces fonctions
• Ajoutez cette protection ici

L’examen examine maintenant le résultat :

• Ce code généré a-t-il manqué des limites ?
• Y a-t-il de nouveaux effets secondaires introduits ?
• Avez-vous tranquillement changé la sémantique de l’ancienne logique ?

Ce n’est pas le même genre de travail.

Le premier consiste à juger le processus de raisonnement de l’auteur, et le second consiste à trouver des pièges dans un code inconnu. Ce dernier est plus coûteux et repose davantage sur la familiarité du critique avec le contexte.

Vous verrez bientôt un phénomène :

• Le code est fusionné
• Quelque chose s’est mal passé en ligne
• Lors de la révision, personne n’a pu dire pourquoi c’était écrit ainsi.

Parce que le « pourquoi » n’est jamais écrit.

2) Les tests sont traités comme « facultatifs »

La plus grande tentation de générer du code est la suivante : il semble complet.

Les fonctions sont joliment décomposées, les noms sont les mêmes et même quelques tests uniques supplémentaires sont fournis.

Le problème est que ces tests unitaires « vérifient souvent la mise en œuvre » plutôt que « vérifient les exigences ».

Les symptômes typiques sont :

• Couverture accrue
• Beaucoup d’accidents

Parce que ce qui manque, ce sont des critères d’acceptation, pas un manque de format JUnit/pytest.

3) Le chemin de restauration est oublié

Les modifications manuscrites conduisent souvent à des réflexions naturelles sur « et si cela ne fonctionne pas ».

Générer des changements peut facilement donner l’illusion qu’il s’agit d’une implémentation plus propre et que cela devrait aller.

Mais le plus douloureux en ligne, c’est que « les changements sont trop importants et vous ne pouvez pas revenir en arrière ».

Lorsque les modifications générées s’étendent sur plusieurs fichiers et sont refactorisées à plusieurs endroits, la restauration ne consiste plus à annuler une validation, mais à reconstruire l’ancienne sémantique.

Il s’agit du projet de loi le plus coûteux après le déplacement des limites des responsabilités.

Pour ramener les limites de la responsabilité, ce que nous devons faire n’est pas de « désactiver le Codex »

Lorsque de nombreuses équipes constatent ces problèmes, leur première réaction est de restreindre leur utilisation :

• Désactiver la génération de grands segments
• La modification des modules de base est interdite
• La logique des clés doit être écrite à la main

Ces règles sont utiles à court terme, mais deviennent vite formalistes.

L’approche véritablement efficace consiste à faire avancer la partie « responsabilité de l’auteur » dans le processus d’utilisation du Codex.

Je l’ai finalement réduit à quatre exigences strictes. S’il en manque un, je n’abandonnerai pas :

1. L’intention de changement doit être écrite clairement : décrivez le comportement à modifier en une phrase, et non « refactorisez-le ».
2. Les critères d’acceptation doivent être applicables : quels sont les intrants, quels sont les résultats attendus et comment se comporter en cas d’échec.
3. La limite de risque doit être répertoriée : Quels appelants sont concernés par ce changement et quel est le pire des cas ?
4. Le plan de restauration doit être clair : vers quelle version revenir, comment traiter les données et où se trouve le commutateur de rétrogradation.

Le Codex peut aider à rédiger des implémentations, mais il ne peut pas remplacer ces quatre éléments.

Plus important encore : après avoir écrit ces quatre articles, la critique est devenue plus légère.

L’examinateur n’a pas besoin de deviner « ce que vous voulez faire exactement » à partir du code, mais doit seulement juger « si l’intention écrite et la mise en œuvre sont cohérentes ».

Les malentendus les plus courants

Malentendu 1 : Traiter le Codex comme « un nouveau venu capable d’écrire du code »

Les nouveaux arrivants se retrouvent coincés dans des endroits qu’ils ne connaissent pas, posent des questions et exposent leur incertitude.

Ce n’est pas le cas du Codex.

Il vous donnera la réponse qui vous semble la plus confortable lorsque vous n’êtes pas sûr. Sans critères d’acceptation, cela enfouit l’incertitude dans le code.

Mythe 2 : Utiliser davantage de mots rapides pour compenser les processus d’ingénierie manquants

Les mots-clés peuvent l’aider à mieux correspondre au style, mais ils ne peuvent pas remplacer le mécanisme de contrôle.

Insérer les processus manquants dans l’invite aboutira à une « mémoire organisationnelle écrite de plus en plus longtemps », mais elle n’a aucun contrôle de version, aucune stratégie de restauration et aucun exercice d’échec.

Malentendu 3 : Ne compter que « combien de temps est gagné »

La mesure la plus dangereuse est la suivante : combien de temps de développement est économisé par exigence.

Parce que cela poussera chacun à poursuivre une plus grande portée de génération.

Je préfère me concentrer sur deux indicateurs :

• Générer un taux de retouche après l’intégration des changements
• Proportion d’incidents introduits par les changements de génération

Ils sont liés aux limites de responsabilité.

Limites applicables

Toutes les équipes n’ont pas besoin de contraintes aussi lourdes.

Si le système est suffisamment petit, les versions assez fréquentes et les retours en arrière assez simples, le risque du Codex sera englouti.

Mais une fois que l’un des éléments suivants est satisfait, les limites des responsabilités doivent être explicitées :

• Les changements affecteront les liens coûteux tels que le paiement, le contrôle des risques et l’approbation.
• Cycle de publication long et coût de restauration élevé
• La propriété du code est ambiguë et la révision est déjà un goulot d’étranglement

Dans ces scénarios, le « plus rapide » du Codex poussera d’abord vers le plus lent.

Résumé

Le Codex accélère certainement l’écriture du code.

Mais ce que cela change réellement, c’est la réponse par défaut de l’équipe à la question « qui est responsable du changement ? »

Si l’intention, l’acceptation, les limites et les retours en arrière ne sont pas avancés, la responsabilité incombera naturellement à l’examinateur.

En fin de compte, vous constaterez que ce qui est économisé n’est pas du temps de développement, mais l’attention de toute l’équipe est dépensée. Ce compte est beaucoup plus cher qu’un jeton.