Le code généré se repère immédiatement: fonctions bien nommées, formatage impeccable, docstrings qui brillent, noms de variables trop précis, aucune variable a, b, x, tmp, out, typage strict des entrées et sorties etc. Un niveau de détail souvent trop fin,
Un processus de relecture de code me semble indispensable; un nom de variable ne peut pas être 'trop' précis, quand au nommage ret, out, var_a_retourner, c'est au contraire super précis, c'est ce qu'on va renvoyer, comme la fonction doit tenir sur un écran maxi, on a même la description highlighté avec le nom de la fonction, et c'est facile à suivre.
Pas de structure, fonctions fleuves de 100 lignes,
là encore, relecture de code
Quant au typage :
l'inverse d'un code en cours d'écriture.
Venant d'un monde où le typage statique est la norme, ça me parait la base de tout code, y compris en cours d'écriture.
Certains codes écrits n'importe comment se repèrent au premier coup d'œil. C'est une alerte. Pas de structure, fonctions fleuves de 100 lignes, pas de séparation fond/forme. Un brouillon intégral. Et les brouillons doivent être réécrits.
Relecture + chaine d'intégration avec sonar intégré, refus de merge en dessous d'une certaine note :)
pas de séparation fond/forme.
ça arrive aussi avec les llm, j'avais demandé un tableau en java, il m'a confondu le model avec la jtable, les deux étant intrinsèquement liés, alors quand j'ai demandé l'ajout des filtre ça a été une vraie boucherie, d'un code lisible quoi qu'un peu spaghetti, c'est devenu l'horreur. :)
Il a d'ailleurs été incapable de séparer le tout, le code qu'il donnait était non compilable.
Avec ce code aseptisé, je vais peut-être perdre du temps.
Pas forcément pour la génération initiale, mais en un rien de temps ça peut devenir très moche :)
Ensuite je ne lui ferai pas confiance sur le choix des technos, ou mécanismes à employer, elle aura une réponse de généré, mais pas forcément la meilleur, toujours sur le même projet je lui ai demandé d'écouter le presse papier (pour envoyer les donnée à un parseur, puis envoyer une notification d'update pour remplir la table)
j'ai eu le droit à un scan périodique plutôt qu'un listener, pas de check de l'existence de la donnée avant de l'envoyer à la table, (en même temps une fois demandé, c'est l'id que l'ia avait décidé d'ajouter elle même a toute les lignes de la table (sans l'afficher) qu'elle a décider d'utiliser et non la variable du record appelé id dans les données...
Bref décrire une fonction, pas de soucis, générer des données de tests, aucun problème (bon faut corriger à la main, mais ça fait gagner du temps), lui poser des question sur quelles solutions utiliser pour : "description du problème" top. Analyser des sortie d'erreur, la encore top.
Bref de mon expérience faut la driver de très près, surveiller les errements, les corriger dès qu'ils surviennent même si le code à l'aire propre, ne pas hésiter a poser la question pourquoi t'as fais ça comme ça...
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
# Que dire...
Posté par fearan . En réponse au journal Je lis du code généré. Évalué à 3.
Si toutes les remarques que tu fais sont exacte :
revois ton processus de dev.
Un processus de relecture de code me semble indispensable; un nom de variable ne peut pas être 'trop' précis, quand au nommage ret, out, var_a_retourner, c'est au contraire super précis, c'est ce qu'on va renvoyer, comme la fonction doit tenir sur un écran maxi, on a même la description highlighté avec le nom de la fonction, et c'est facile à suivre.
là encore, relecture de code
Quant au typage :
Venant d'un monde où le typage statique est la norme, ça me parait la base de tout code, y compris en cours d'écriture.
Relecture + chaine d'intégration avec sonar intégré, refus de merge en dessous d'une certaine note :)
ça arrive aussi avec les llm, j'avais demandé un tableau en java, il m'a confondu le model avec la jtable, les deux étant intrinsèquement liés, alors quand j'ai demandé l'ajout des filtre ça a été une vraie boucherie, d'un code lisible quoi qu'un peu spaghetti, c'est devenu l'horreur. :)
Il a d'ailleurs été incapable de séparer le tout, le code qu'il donnait était non compilable.
Pas forcément pour la génération initiale, mais en un rien de temps ça peut devenir très moche :)
Ensuite je ne lui ferai pas confiance sur le choix des technos, ou mécanismes à employer, elle aura une réponse de généré, mais pas forcément la meilleur, toujours sur le même projet je lui ai demandé d'écouter le presse papier (pour envoyer les donnée à un parseur, puis envoyer une notification d'update pour remplir la table)
j'ai eu le droit à un scan périodique plutôt qu'un listener, pas de check de l'existence de la donnée avant de l'envoyer à la table, (en même temps une fois demandé, c'est l'id que l'ia avait décidé d'ajouter elle même a toute les lignes de la table (sans l'afficher) qu'elle a décider d'utiliser et non la variable du record appelé id dans les données...
Bref décrire une fonction, pas de soucis, générer des données de tests, aucun problème (bon faut corriger à la main, mais ça fait gagner du temps), lui poser des question sur quelles solutions utiliser pour : "description du problème" top. Analyser des sortie d'erreur, la encore top.
Bref de mon expérience faut la driver de très près, surveiller les errements, les corriger dès qu'ils surviennent même si le code à l'aire propre, ne pas hésiter a poser la question pourquoi t'as fais ça comme ça...
Il ne faut pas décorner les boeufs avant d'avoir semé le vent