Discussion :

[Franck SORIANO]

Là tu parle de correction de bug, qui implique parfois de refaire une portion non négligeable du code.

J'ai pris un exemple de correction de bug, mais on peut dire la même chose pour une évolution : "Tu appelles une méthode qui devait faire un certain calcul, elle le faisait bien mais maintenant le calcul doit être fait différemment..."

dans le cadre du refactoring, si je ne me trompe pas, on parle de refaire un code qui marche afin de le rendre plus facilement maintenable et/ou plus efficace et/ou plus logique?

On modifie un code à transformation ISO : ISO fonctionnel, ISO bug...
"plus facilement maintenable" : On cherche a gagner en lisibilité, à éviter les redondances de codes inutiles... donc je suis d'accord avec toi, l'objectif est d'arriver à un code plus lisible et donc plus maintenable.

"et/ou plus efficace" : La j'ai du mal à imaginer que le code puisse devenir plus efficace sans remettre en cause le traitement et ça logique. Pour moi, ce n'est plus du simple refactoring (sauf peut-être à passer par une variable locale au lieu d'appeler 50 fois la même fonction qui retournera toujours le même résultat.

"et/ou plus logique" : Ca veut dire que tu changes la logique de ton code (donc tu changes tes algo). Pour moi, ce n'est plus du refactoring.

[jabbounet]

J'ai pris un exemple de correction de bug, mais on peut dire la même chose pour une évolution : "Tu appelles une méthode qui devait faire un certain calcul, elle le faisait bien mais maintenant le calcul doit être fait différemment..."

oui on peux, ça rentre dans le cadre d'une tma ou tu as de la maintenance évolutive (en générale sur de petits volumes) et corrective....

"et/ou plus efficace" : La j'ai du mal à imaginer que le code puisse devenir plus efficace sans remettre en cause le traitement et ça logique. Pour moi, ce n'est plus du simple refactoring (sauf peut-être à passer par une variable locale au lieu d'appeler 50 fois la même fonction qui retournera toujours le même résultat.

effectivement c'est du refactoring + amélioration de perfs.

"et/ou plus logique" : Ca veut dire que tu changes la logique de ton code (donc tu changes tes algo). Pour moi, ce n'est plus du refactoring.

plus logique dans le sens ou il est possible, sans changer d'api externe, que plusieurs algo totalement différent arrivent aux mêmes résultats en interne dans ton appli, simplement certains seront plus facile à comprendre/maintenir car plus simple et moins tordu.

[gl]

Voilà une bonne définition d'un code déjà bien propre

Non, dans ce cas, ce n'est pas le code qui explique ce qui doit être fait mais les spécifications et tests unitaires.

La remarque de Franck était :

C'est très simple : Tu connais le projet, tu connais les spécifications. Tu sais que lorsque tu appelles cette méthode, elle doit réaliser ce calcul. Les tests te montre qu'elle calcule faux. Tu rentres dans le code pour la déboguer et lorsque tu vois l'usine à gaz totalement incompréhensible qui se trouve derrière alors que le problème était tout simple, tu te dit : J'aurais plus vite fait de tout réécrire plutôt que d'essayer de comprendre ce que le mec avant moi a voulu faire...

[hegros]

Non, dans ce cas, ce n'est pas le code qui explique ce qui doit être fait mais les spécifications et tests unitaires.

Je pense que la remarque sur le code propre venait de

tu sais que lorsque tu appelles cette méthode, elle doit réaliser ce calcul.

En d'autre terme que la méthode à un nom qui explicite la spécification. Une méthode qui s'appelle "Additionner2Nombres" explique clairement les intentions de calcul alors que si elle s'appelait toto cela en serait autrement (code sale car tu ne peux pas savoir ce qu'elle est sensée faire toto n'a aucun sens)

[Nebulix]

Non, dans ce cas, ce n'est pas le code qui explique ce qui doit être fait mais les spécifications et tests unitaires.

Mais si les spécifications ne sont pas indissolublement liées au code, elles seront introuvables quand on en aura besoin.

[jabbounet]

Mais si les spécifications ne sont pas indissolublement liées au code, elles seront introuvables quand on en aura besoin.

là c'est plus un problème de suivi du logiciel.

[hegros]

là c'est plus un problème de suivi du logiciel.

Pas seulement car quand tu as une spécification qui te dis qu'il faut calculer la somme des taxes comment tu te retrouves dans le code en maintenance si toutes les méthodes s'appellent toto ?

Rajouter des documents de suivi pour dire telle spécification c'est telle ligne de programme ou telle module ne sera jamais à jour il deviendra avec le temps et les opérations de maintenance au mieux une rumeur...

Le code c'est la vraie spécification...exécutable. Les autres documents c'est des rumeurs

[jabbounet]

Pas seulement car quand tu as une spécification qui te dis qu'il faut calculer la somme des taxes comment tu te retrouves dans le code en maintenance si toutes les méthodes s'appellent toto ?

il y'a aussi les documents de conception détaillée, si c'est bien fait tu dois pouvoir t'y retrouver.

Rajouter des documents de suivi pour dire telle spécification c'est telle ligne de programme ou telle module ne sera jamais à jour il deviendra avec le temps et les opérations de maintenance au mieux une rumeur...

Cela dépend du secteur et de l'importance que tu accorde aux docs de spec/conception, quand j'étais dans le ferroviaire, je peux te garantir qu'aucune fonction n'était pas décrite en détail dans un document (à la variable locale près).
Maintenant je suis dans le télécom et c'est plutôt le contraire.

Le code c'est la vraie spécification...exécutable. Les autres documents c'est des rumeurs

Oui, sauf le jour ou tu tombe sur un projet qui a pour finalité d'être normé SIL4 et que les tests unitaire doivent atteindre 100% de couverture de code/branche/condition et que les testeurs n'ont pas d'accès direct au code (en tout cas pas officiellement).
A partir de là je peux te garantir que tes doc de conception sont au même niveau que le code car sinon tu te fais taper sur les doigts


Mais bon quand tu met cela en place, ce n'est pas le même budget en général.

[hegros]

il y'a aussi les documents de conception détaillée, si c'est bien fait tu dois pouvoir t'y retrouver.

Assez rare du fait que cela lie 2 disciplines pas trop maîtrisées, estimées en général comme une perte de temps et surtout pas très bien enseignées (concevoir et documenter) En même temps je me base sur ma pauvre expérience dans l'industrie chimique et médical ainsi que sur mon cursus de formation.

Oui, sauf le jour ou tu tombe sur un projet qui a pour finalité d'être normé SIL4 et que les tests unitaire doivent atteindre 100% de couverture de code/branche/condition et que les testeurs n'ont pas d'accès direct au code (en tout cas pas officiellement).
A partir de là je peux te garantir que tes doc de conception sont au même niveau que le code car sinon tu te fais taper sur les doigts

Je ne vois pas comment un testeur ou quelqu'un d'autre pourrait faire passer des tests unitaires sans avoir accès au code, c'est impossible

[Franck SORIANO]

Le code c'est la vraie spécification...exécutable.

Pas vraiment. Les spécifications, c'est ce que tu veux/voulais que le code fasse (ou qu'il aurait dû faire) alors que le code, c'est ce qu'il fait réellement.
Idéalement, lorsque tu livres l'appli finale, les deux devraient dire la même chose.

Mais comment tu fais pour corriger un bug, si le code est ta spécification ? Tu ne peux alors plus savoir que ce que le code fait (en supposant qu'il soit suffisamment lisible), mais pas ce qu'il devait faire !

Je ne vois pas comment un testeur ou quelqu'un d'autre pourrait faire passer des tests unitaires sans avoir accès au code, c'est impossible

Ca c'est parce que pour toi spécifications = code.
Les tests s'établissent à partir des spécifications : Tu vérifies que le code fait bien ce que les specs disaient qu'il devait faire. Si tes specs sont bien définies indépendamment du code, tu n'as pas besoin du code pour savoir ce que tu dois tester.

Par contre, je ne vois pas comment on peut mesurer la couverture des tests par rapport au code, sans voir le code (sous une forme ou une autre).

[hegros]

Pas vraiment. Les spécifications, c'est ce que tu veux/voulais que le code fasse (ou qu'il aurait dû faire) alors que le code, c'est ce qu'il fait réellement.
Idéalement, lorsque tu livres l'appli finale, les deux devraient dire la même chose.

Tu noteras la nuance tout de même, je parlais de spécification exécutable. Au delà de cela il y a effectivement tout un tas d'autres spécifications : fonctionnelles, systèmes, techniques, hardware, non fonctionnelle etc etc...

Mais comment tu fais pour corriger un bug, si le code est ta spécification ? Tu ne peux alors plus savoir que ce que le code fait (en supposant qu'il soit suffisamment lisible), mais pas ce qu'il devait faire !

cela dépend si c'est un bug qui touche le fonctionnel ou la technique. Si j'ai un bug parce que j'ai oublié d'allouer un pointeur ou de libérer la mémoire alors la spécification ne me sera d'aucune utilité, de même si j'ai écris a=6 au lieu de a==6 pour un test d'égalité la spécification ne me sert à rien non plus.

Ca c'est parce que pour toi spécifications = code.

non, code = spécification exécutable ce n'est pas toutes les spécifications, ma phrase allait plutôt dans le sens : c'est la seule spécification qui au final compte.

Effectivement tu n'as pas besoin de code pour écrire un test unitaire je pense que l'approche DDT en est un bon exemple par la pratique

[jabbounet]

Par contre, je ne vois pas comment on peut mesurer la couverture des tests par rapport au code, sans voir le code (sous une forme ou une autre).

c'est pour cela que j'ai dit pas officiellement accès au code....

autrement à l'époque on utilisait cet outil pour les tests unitaire
http://www-01.ibm.com/software/awdto...ime/index.html

[Nebulix]

là c'est plus un problème de suivi du logiciel.

Donc c'est la faute d'un collègue, pas la tienne
mais
ça ne résoud pas le problème
il est dommage de ne pas prévenir l'incident quand c'est si facile

[jabbounet]

Donc c'est la faute d'un collègue, pas la tienne
mais

C'est aussi le tiens, si tu as un rôle quelconque par rapport au devenir de ce logiciel, que ce soit en tant que codeur ou big boss , chaque personne a sa part de responsabilité.
je suis peu être un peu bête mais j'ai horreur de me défausser sur quelqu'un d'autre...

ça ne résoud pas le problème
il est dommage de ne pas prévenir l'incident quand c'est si facile

il est en effet toujours mieux d'anticiper un minimum, cela entre dans le cadre de la gestion des risque, simplement personne n'est parfait et devin.

[Nebulix]

C'est aussi le tiens, si tu as un rôle quelconque par rapport au devenir de ce logiciel, que ce soit en tant que codeur ou big boss , chaque personne a sa part de responsabilité.
je suis peu être un peu bête mais j'ai horreur de me défausser sur quelqu'un d'autre...

Le style direct d'un forum peut conduire à des incompréhensions. Le "tu" que j'ai employé s'adresse à tout le monde, moi compris. Nous sommes là pour partager nos expériences et améliorer nos pratiques, exprimer des désaccords, pas critiquer des personnes. Si tu t'es senti personnellemnt visé, je te prie de m'excuser.

[jabbounet]

Le style direct d'un forum peut conduire à des incompréhensions. Le "tu" que j'ai employé s'adresse à tout le monde, moi compris. Nous sommes là pour partager nos expériences et améliorer nos pratiques, exprimer des désaccords, pas critiquer des personnes. Si tu t'es senti personnellemnt visé, je te prie de m'excuser.

T'inquiete il en faut plus que cela pour me sentir visé . et effectivement avec un forum il manque une bonne partie de la communication que tu peux avoir a l'oral (gestuelle,...)

[ouhraniufr]

Bonjour,
Qui peut me dire, comment peut on améliorer la lisibilité d'un code? je serai très reconnaissante si je trouve une repense
Merci

[gangsoleil]

Bonjour,

Ca depend d'ou tu pars.

Si le code est obfusque et illisible, il faut commencer par le rendre comprehensible : renommer les fonctions, commenter, aerer, ...

Si le code est au contraire lisible et commente, on peut passer a de la doc generee type doxygen, ...

[el_slapper]

Bonjour,
Qui peut me dire, comment peut on améliorer la lisibilité d'un code? je serai très reconnaissante si je trouve une repense
Merci

Très bonne question, mais la réponse dépend fortement du langage - et de son état. Je peux te donner des conseils pour du Cobol généré automatiquement(une horreur que j'ai appris à dompter par la force des choses), mais pas pour du java(dont les contraintes structurelles sont radicalement différentes).

Un truc quand même : les tests. Rendre un code plus lisible, c'est prendre le risque de le casser(surtout si on réorganise un boucle qui fait 2 pages et qui tourne sur des GO TO et des compteurs gérés en dur). Donc, avoir une couverture de tests complète, si possible automatique, pour vérifier qu'on ne casse rien. Et avoir les moyens de revenir en arrière(versions, sauvegardes...).

[koala01]

Bonjour,
Qui peut me dire, comment peut on améliorer la lisibilité d'un code? je serai très reconnaissante si je trouve une repense
Merci

De manière très générale (car toutes les situations sont différentes), je conseillerais, dans un premier temps:

1. de choisir des noms explicites (qui indiquent, rien qu'à la lecture, de que l'on fait), en fonction des restrictions imposées par le langage
2. de respecter des règles strictes de nommages (éviter d'avoir un nom de fonction qui commence par une majuscules et un autre qui commence par une minuscule, par exemple )
3. d'indenter correctement les différents blocs les uns par rapport aux autres, de manière à pouvoir les repérer
4. de respecter la règle d'une ligne par instruction
5. de placer les symboles de blocs (si le langage en définis) même lorsqu'ils ne sont pas requis
6. de ne pas hésiter à commenter un bloc de code qui serait vraiment trop nébuleux (en veillant cependant autant que possible à décrire la raison pour laquelle on fait quelque chose et non ce que l'on fait )
7. d'éviter autant que possible les sucres syntaxiques s'ils n'apportent vraiment rien

Dans un deuxième temps, on peut envisager un refactoring au niveau des fonctions en:

1. séparant correctement les différentes responsabilités de sorte à ce que chaque fonction n'en ai pas plus d'une
2. factorisant au besoin certains blocs de fonction
3. essayant d'arriver à des fonctions de "taille acceptable": 20 à 30 lignes ( +/- XX ) par fonction, c'est déjà pas mal

Si le code reste encore nébuleux malgré tout cela, peut etre faudra-t-il refactorer plus en profondeur, mais on entre alors dans un autre débat qui tient carrément de la conception