Tout accepter, ne rien comprendre

Appuyer sur Entrée pour accepter des suggestions de code demande moins d'effort que de les faire défiler. Une seule touche et le code est à vous. La lecture et la compréhension de ce code, quant à elles, n'ont pas progressé.

Il existe un fossé entre la rapidité avec laquelle vous acceptez le code et la rapidité avec laquelle vous le comprenez. C'est dans ce fossé que les erreurs surviennent.

La dette technique avait autrefois des causes claires. Vous aviez des délais serrés ou vous preniez des raccourcis. Vous pouviez en identifier la raison. Aujourd'hui, vous accumulez de la dette un mardi calme. Vous acceptez six suggestions d'affilée parce qu'elles semblent correctes. Personne ne vous a pressé, mais le code reste inexploré.

En 1974, Brian Kernighan disait que le débogage est deux fois plus difficile que l'écriture d'un programme. Il parlait du code écrit par des humains. Au moins, les humains comprennent leur propre travail.

Aujourd'hui, une suggestion peut passer le linter et même réussir les tests. Elle peut pourtant reposer sur une hypothèse erronée. Cela arrive parce que les gens lisent la suggestion comme un résultat plutôt que comme du code. Un résultat qui semble correct est approuvé.

Si un modèle écrit à la fois le code et les tests, vous corrigez un devoir avec les propres réponses de l'élève. Cela ne vous dit pas si la logique est solide. Cela ne vous dit pas si les cas limites sont couverts. Il est facile d'oublier cela lorsque le code apparaît dans votre propre éditeur et avec votre propre style.

Cela crée de réels problèmes :

  • Vous déboguez du code que vous n'avez jamais lu. Quand quelque chose casse des semaines plus tard, vous repartez de zéro.
  • Les cas limites échouent. Une suggestion gère bien le chemin nominal. Elle inclut une vérification de nullité. Mais elle passe à côté de la logique spécifique dont votre entreprise a besoin.
  • Vous ne pouvez pas défendre vos propres pull requests. Si un relecteur vous demande pourquoi vous avez choisi une méthode, vous n'avez pas de réponse. Vous n'avez pas pris la décision. Vous ne l'avez simplement pas rejetée.

Ces outils sont utiles. Ils vous aident à explorer des bases de code ou à planifier de nouvelles fonctionnalités. Le problème réside dans votre posture. Vous devez traiter chaque suggestion comme quelque chose à lire et à valider, et non comme quelque chose que l'on survole du regard.

Pour le boilerplate ou les scripts rapides, la vitesse est acceptable. Pour la logique métier ou la sécurité, votre approche doit changer. Lisez le code comme si vous alliez en être responsable. Parce que ce sera le cas.

Faites plutôt ceci :

  • Discutez de votre solution avec le modèle avant de demander du code.
  • Examinez le diff comme si vous l'aviez écrit vous-même.
  • Demandez à l'outil d'expliquer son raisonnement avant d'accepter le code.
  • Traitez les suggestions comme le travail d'un développeur junior. C'est utile, mais ce n'est pas une vérité absolue.
  • Ralentissez sur les lignes qui vous surprennent. La surprise est un signal.

L'appui sur une touche est devenu moins coûteux. Votre responsabilité, elle, ne l'est pas. La vitesse sans compréhension n'est que de la dette accélérée.

Source : https://dev.to/cloudx/accept-all-understand-none-4dob

Communauté d'apprentissage optionnelle : https://t.me/GyaanSetuAi