Discussion :

[sleepy2002]

A souviron34,

Du coup la problématique est au niveau du management de l'équipe.

Comment effectuer un transfert et le partage des connaissances dans une équipe qui bouge ? Le binômage et la rotation des binômes peut résoudre ce souci (à part dans les cas où la direction vire tout le monde)

Comment donner confiance à l'équipe, leur donner le sentiment de maîtriser un logiciel qui a 2 000 000 lignes de codes? Encore une fois à des tests unitaires et d'intégration.

[pseudocode]

Je prend le cas du truc sur lequel je bosse : le coeur est secret, privé, et nous n'avons pas le droit d'y toucher. On refait tout le tour, mais pas l'intérieur .. Et même si il va falloir que je le touche pour le rendre compatible avec l'évolution actuelle, je ne me risquerais pas à toucher quoi que ce soit des algos et découpages et noms (trop de vies en jeu, alors que cela marche comme ça depuis 25 ans).

Je vais juste permettre d'accepter nos nouvelles données en entrée et récupérer les sorties... Mais je n'ai pas envie de me retrouver avec 20 000 morts à mon actif, donc je ne re-factore rien du tout

Le refactor n'est pas obligatoirement sur le code mais aussi sur l'architecture. Nous avons aussi des applis avec une partie "boite noire" qu'on ne doit pas toucher. La boite noire est encapsulée dans un objet donc on maitrise les responsabilités (utilise quoi, quand, par qui ...). Au grès des évolutions, on refactor le design et donc on modifie les responsabilités de l'objet englobant, sans pour autant toucher au code "boite noire".

Le refactoring n'est pas systématique, cela dépend des besoins. Privilégier une conception simple marche et qui évoluera au fil du temps plutôt que de vouloir sortir tout de suite un truc "méta générique".

Je dirais meme qu'il faut éviter le "méta générique" inutile. Le principe KISS doit prévaloir sur les aspirations idéalistes . Ca n'empêche pas de respecter certaines règles de bases (paradigmes, patterns, ...), mais inutile de sur-désigner le programme pour faire "beau".

[sleepy2002]

Le MOA n'EST PAS un utilisateur....
Par conséquent ce n'est pas un bon test...

Je suis d'accord en ce qui concerne le premier point. Le deuxième moins. Le besoin à l'instant t0 n'est pas final. La vision du client évolue (> 80% des cas) et par conséquent ton code aussi.

Il y 3 mois nous avons dû implémenter une fonctionnalité assez compliquée et bien sûr nous n'avions pas tous les cas d'utilisation en tête. En recette, les utilisateurs ont noté des bugs suite à des cas que nous n'avons pas pensé. Pas grave, nous avons créé une tâche puis mis à jour le code.

Résultat, cette fonctionnalité a subi 7 évolutions avant d'entrer en production.

Le test n'est pas "bon" au début mais au fil des utilisations en recette, il s'améliorera.

[sleepy2002]

Au grès des évolutions, on refactor le design et donc on modifie les responsabilités de l'objet englobant, sans pour autant toucher au code "boite noire".

C'est le principe d'ouverture / fermeture

[Matthieu Brucher]

Tu n'en es pas un ?

Mais de toutes façons, comme on va le dire plus bas...

Les tests ne suffisent pas..

Et d'autre part, si il fallait un informticien patenté derrière chaque ingénieur pour chaque programme scientifique, on n'en finit pas..

Parce que, au fait, pour faire un programme qui doit faire ce qu'il faut (dans le métier), et si tu n'y connais rien, il faut que tu commences par prendre un cours (ce qui veut dire dans la majeure partie des cas faire 5 ans d'études supplémentaires et 10 ans d'expérience)... Ou alors écrire 250 pags de doces alors qu'on n'est même pas sûr du résultalt..

Je suis actuellement "informaticien" plus que scientifique.
Est-ce que j'ai dit que les tests suffisaient ? Non. Encore une fois, ne me fais pas dire ce que je n'ai pas dit. J'ai dit que les ingénieurs qui créaient des nouveaux codes, les scientifiques, devraient s'attacher un peu plus à cet outil (l'informatique, Computer Science). On ne demande pas qu'ils soient nickel (sinon, on aurait plus de boulot ), mais le minimum de connaissance, ce serait bien. Et pas besoin de 5 années d'études. 2-3 mois à travailler régulièrement permettrait d'avoir au moins un début de sensibilité.
Il n'est pas nécessaire d'avoir un informaticien derrière chaque scientifique. Ici, je suis seul pour une équipe de 5-6 personnes (et tous ne développent pas).

Les TU ne prouvent RIEN...

Et toutes les méthodes se BASANT là-dessus ont , elles, prouvé qu'elles ne marchaient pas (le cycle en V bête).

Ce n'est pas parce que les TU marchent que l'appli fait ce q'elle doit faire...

Complètement d'accord. Le comportement microscopique ne veut pas dire que le macroscopique est correct.

+1 pour le KISS, +1 pour les problématiques de transferts de connaissance (on change d'affectation tous les 4 ans en moyenne, c'est dire).
+1 aussi pour la problématique de tester une application. Ce qui se passe chez nous, c'est que l'application passe en préproduction, on a des utilisateurs type qui font des retours, et on voit.

[souviron34]

Du coup la problématique est au niveau du management de l'équipe.

Comment effectuer un transfert et le partage des connaissances dans une équipe qui bouge ?

je ne me pose guère le problème par rapport à une équipe qui bouge, mais une équipe qui disparaît : transfert extérieur, rachat de l'entreprise, abandon temporaire (> 1 an) de la maintenance, puis reprise après, etc etc.

Cela m'est arrivé 4 fois en 15 ans, et à chaque fois c'est la m.rde...

Et les TU ne te servent plus lorsque tout est intégré, et qu'il faut retracer pièce à pièce ....

Le refactor n'est pas obligatoirement sur le code mais aussi sur l'architecture. Nous avons aussi des applis avec une partie "boite noire" qu'on ne doit pas toucher. La boite noire est encapsulée dans un objet donc on maitrise les responsabilités (utilise quoi, quand, par qui ...). Au grès des évolutions, on refactor le design et donc on modifie les responsabilités de l'objet englobant, sans pour autant toucher au code "boite noire".

Oui, mais quand ta "boîte noire" est constituée de 60 fichiers, 300 fonctions, une 50aine de COMMON, et un programme qui pilotait l'interface et non l'inverse, c'est pas mal compliqué

Si la philosophie du développement ancien était contraire à ce que tu ferais aujourdhui, c'est assez problèmatique, et quand ta "boite noire" est plutot une "boite grise", ou "à pois", avec des trous partout, ben...

Ton architecture "nouvelle" va en prendre un coup...

[souviron34]

Il y 3 mois nous avons dû implémenter une fonctionnalité assez compliquée et bien sûr nous n'avions pas tous les cas d'utilisation en tête. En recette, les utilisateurs ont noté des bugs suite à des cas que nous n'avons pas pensé.

justement parce que le MOA n'était pas un utilisateur

et n'avait sans doute pas appliqué une vraie démarche ergonomique..

Maintenant, que les besoins évoluent, certes, je suis bien d'accord..

Mais ce dont on est parti, "un code propre", n'a qu'une petite partie à voir avec ça....

[sleepy2002]

Et les TU ne te servent plus lorsque tout est intégré, et qu'il faut retracer pièce à pièce ....

Grave erreur, le feedback (composante importante dans XP) est plus rapide.

Tu modifies un maillon de ta chaîne, est-tu sûr qu'il respecte le contrat ?

Tu construis ton application et là paf ! bug lors des tests intégrations. Où il est ? Quelle partie/maillon/pièce a fait planté mon test d'intégration.
Avec le TU de ton maillon, tu vois tout de suite si ta modification a entraîné des régressions.

[sleepy2002]

justement parce que le MOA n'était pas un utilisateur

et n'avait sans doute pas appliqué une vraie démarche ergonomique..

Oui et non, on ne va pas poireauter 2 mois de specs fonctionnelles avant de commencer le code alors qu'un cycle de développement itératif incrémentale permet de sortir un prototype et avoir un feedback de l'utilisateur rapidement.

Mais tu as raison, je m'égare

[souviron34]

J'ai dit que les ingénieurs qui créaient des nouveaux codes, les scientifiques, devraient s'attacher un peu plus à cet outil (l'informatique, Computer Science).
...Il n'est pas nécessaire d'avoir un informaticien derrière chaque scientifique. Ici, je suis seul pour une équipe de 5-6 personnes (et tous ne développent pas).

Je ne sais pas avec quels scientifiques tu travailles, mais ceux avec qui j'ai travaillé étaint tous sensibilisés et faisaient tous des tests.... (et j'en suis un )

Mais également, par exemple, la plupart de ceux avec qui j'ai travaillé dans les 20 dernières années, faisaient le développement ET la maintenance du code opérationnel, et étaient responsables légalement de bugs ou des résultats.

Le "Service Info" était juste là pour gérer les machines, les accès hard, etc etc..


.

Complètement d'accord. Le comportement microscopique ne veut pas dire que le macroscopique est correct.

+1 pour le KISS, +1 pour les problématiques de transferts de connaissance (on change d'affectation tous les 4 ans en moyenne, c'est dire).
+1 aussi pour la problématique de tester une application. Ce qui se passe chez nous, c'est que l'application passe en préproduction, on a des utilisateurs type qui font des retours, et on voit.

Bon, nous sommes d'accord

[souviron34]

Grave erreur, le feedback (composante importante dans XP) est plus rapide.

Tu modifies un maillon de ta chaîne, est-tu sûr qu'il respecte le contrat ?

Tu construis ton application et là paf ! bug lors des tests intégrations. Où il est ? Quelle partie/maillon/pièce a fait planté mon test d'intégration.
Avec le TU de ton maillon, tu vois tout de suite si ta modification a entraîné des régressions.

Encore une fois, encore faut-il pouvoir le faire...

Quand le passage par telle fonction nécessite d'être passé par telle et telle autre avant, nécessite d'avoir telle et telle donnée en entrée, et que ce n'est pas du "par contrat", c'est extrêmement difficile... Sans parler de bugs dûs aux allocations/libérations dynamiques, ou au télescopage de plusieurs progarmmes simultanés... Que ce soit en objet ou en procédural, isoler un bug est une technique en soi, qui ne se décrit pas simplement...

Et qui, de surcroît, est nettement plus rapide en utiisant ce que je dis ci-dessous qu'en tentant de faire passer des TU aux 9 000 fonctions précédemment appelllées..



Merci gdb et ddd

[Matthieu Brucher]

Je ne sais pas avec quels scientifiques tu travailles, mais ceux avec qui j'ai travaillé étaint tous sensibilisés et faisaient tous des tests.... (et j'en suis un )

Mais également, par exemple, la plupart de ceux avec qui j'ai travaillé dans les 20 dernières années, faisaient le développement ET la maintenance du code opérationnel, et étaient responsables légalement de bugs ou des résultats.

Le "Service Info" était juste là pour gérer les machines, les accès hard, etc etc..

Il y a des tests fonctionnels, mais c'est tout

[sleepy2002]

Sans parler de bugs dûs aux allocations/libérations dynamiques, ou au télescopage de plusieurs programmes simultanés... Que ce soit en objet ou en procédural, isoler un bug est une technique en soi, qui ne se décrit pas simplement...
Merci gdb et ddd

Là on introduit les tests de charges.

HS : En XP, on préconise la mise de l'intégration continue. Tu "commites" tes modifications et une machine est dédiée pour construire l'application et faire passer tous les tests d'intégration. Feedback assez rapide du coup.

[hegros]

D'autre part, quel critère objectif permet d'affirmer qu'un % de commentaire plus important que le % de code est un problème ?

Pour ma part, si le % de commentaire est plus important que le %de code c'est qu'il y a forcément une duplication ou un problème de plan documentaire niveau projet puisque le code pourrait embarquer les spécifications techniques et d'architecture puis même les algorithmes, les réglés de gestion, d'infrastructure pourquoi pas ?

Ensuite c'est qu'il y a mauvaise utilisation du mauvais outil de développement. Le travail de ce que j'ai cité plus haut se retrouve dans le code ce qui est à mon sens pas la meilleure place.

La doc étant généré à partir du commentaire, il ne peut y avoir d'incohérence entre les deux.

Manuellement si ce n'est pas la même personne qui est chargé de le faire la doc et le code cela ne sera pas à jour et automatiquement c'est pareil quand il y a des personnes qui travaillent sur une version, il est plutôt impossible que la doc générée soit à jour.

Et le processus de génération permet de repérer d'éventuelle différence entre le code et la documentation, ce que ne permet pas une documentation maintenue manuellement indépendant du code.

Oui le processus de génération tout comme la chaîne de compilation est une solution, enfin un process, qui prends en charge le problème de duplication et d'incohérence cependant la duplication peut faire exploser les machines et le process

Quant à l'utilisation du Pascal, je te crois volontiers lorsque tu dis que c'est utilisé, mais dans mon expérience personnelle, je n'en ai jamais rencontré dans de l'embarqué (ce qui ne signifie pas que ce soit insignifiant bien sur).

Je ne parlais pas spécifiquement d'embarqué mais d'appareil electronique au départ. Il est possible que se soit aussi du free pascal ou dérivé, c'est utilisé par des automates programmables industriels dedans on a un processeur, de la mémoire et du réseau d'ailleurs il est possible aussi d'avoir une approche objet maintenant

[gl]

Manuellement si ce n'est pas la même personne qui est chargé de le faire la doc et le code cela ne sera pas à jour et automatiquement c'est pareil quand il y a des personnes qui travaillent sur une version, il est plutôt impossible que la doc générée soit à jour.


Oui le processus de génération tout comme la chaîne de compilation est une solution, enfin un process, qui prends en charge le problème de duplication et d'incohérence cependant la duplication peut faire exploser les machines et le process

Ton argumentation me surprends beaucoup.

En effet, tu prétends qu'il ne faut pas commenter en avançant les deux arguments ci dessous :

• La doc et le code sont écrits par des personnes différentes et donc la doc ne sera pas à jour. Or justement le code et les commentaires qui y sont liés sont généralement écrits par la même personne et en outre la génération de la doc depuis les commentaires permet de détecter une partie des incohérences.
• La saturation des ressources? Sachant que les commentaires dans le code ont généralement une empreinte mémoire plus faible qu'un document externe dans un format type word ou pdf.

Les arguments que tu avances me semble au contraire prêcher en faveur de l'utilisation de commentaires.

A moins que tu ne préconises de supprimer toute forme de documentation et de ne conserver que le code. J'ose espérer que ce n'est pas le cas.

[gl]

Pour ma part, si le % de commentaire est plus important que le %de code c'est qu'il y a forcément une duplication ou un problème de plan documentaire niveau projet puisque le code pourrait embarquer les spécifications techniques et d'architecture puis même les algorithmes, les réglés de gestion, d'infrastructure pourquoi pas ?

Ensuite c'est qu'il y a mauvaise utilisation du mauvais outil de développement. Le travail de ce que j'ai cité plus haut se retrouve dans le code ce qui est à mon sens pas la meilleure place.

Je suis d'accord que les spécifications techniques, l'architecture, la description des algorithmes, le guide utilisateur d'un exécutable, etc. n'ont pas leur place dans les commentaires, et je n'ai jamais prétendu le contraire (et je n'ai vu personne le prétendre ici).

Ma question n'était pas celle-ci mais quels arguments objectifs permettent de dire qu'un % important de commentaires est un problème. Sachant qu'un % important n'implique pas forcément la présence dans ledit commentaire des spécifications, de l'architecture ou du contenu de tout autre document.

Je reformule ma question de manière moins ambiguë si tu préfères : quels arguments objectifs permettent de dire qu'un % de commentaires pertinents plus important que le % de code effectif est un problème ?

[hegros]

Je n'ai jamais exclu toute forme de commentaire dans un programme, une cartouche me semble suffisante c'est une question de découpage.


Aussi dans ce qui a été proposé comme code/commentaire cela ne m'a pas plus aidé c'est en fait rarement pertinent pour ce que je dois comprendre


gl, la documentation ne peut pas être à jour et parfaitement synchronisée avec le code sauf si c'est la finale ce qui veut dire que les personnes partent en retraite ou alors qu'il n'y a aucun bug.


Parce que aussitôt que la documentation est générée le code peut l'être dans les minutes qui suivent (version en paralléle) et les commentaires qui vont avec sinon le niveau d'incohérence atteri dans le code.


Pour essayé de répondre à ta question prenons un exemple bidon.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14

//truc trouvé sur machin.net

//test boucle infini

//voir bug n°123 ligne 6580


//ici plus de memoire physique et virtuelle

//attention algorithme z

//ici c'est coeur du système gaffe !!!!

1-Comment tu documentes cela ?

2-Comment je sais pour qui est-ce que cela est pertinent ?


Tout cela me laisse dire que la pertinence ne me semble pas aussi évidente à évaluer. Aussi cela m'étonne qu'un commentaire soit plus pertinent que le code effectif et c'est ce qui me poserait effectivement un problème puisque cela voudrait dire qu'en plus de me taper la lecture du code pour comprendre il faut aussi lire le commentaire..

[gl]

Je n'ai jamais exclu toute forme de commentaire dans un programme, une cartouche me semble suffisante c'est une question de découpage.

On est donc d'accord. C'est de ce style de commentaire que je parlais comme indiqué dans mon premier message, je cite :

PS: pour préciser clairement le contexte de mon message, je parle ici des commentaires d'en-tête de fichier et d'en-tête de fonction.
Pour les commentaires internes à une fonction/méthode/procédure, j'ai une approche plus minimaliste, commentant uniquement les passages les plus ambigus (tordus?) ou certains choix d'implémentation surprenant qui ne font pas (et n'ont pas à faire) l'objet d'un document externe.

D'ailleurs l'exemple fourni en Java par un autre contributeur et les discussions autour des commentaires en guise de contrat, pré-condition, post_condition, invariant, etc. tournaient autour de ce type de commentaire.

Parce que aussitôt que la documentation est générée le code peut l'être dans les minutes qui suivent (version en paralléle) et les commentaires qui vont avec sinon le niveau d'incohérence atteri dans le code.

Je ne vois pas le problème. Si la génération de la documentation est correctement intégré dans la chaîne de compilation, lors d'une livraison tu as bien un ensemble code+binaire+doc qui est cohérent.

Effectivement la doc ne sera pas cohérent avec une autre version du code, tout comme le binaire généré ne sera pas cohérent avec une autre version du code.
Mais ça n'a pas réellement d'importance, puisque la documentation est liée à une version précise du code (elle même doit être versionnée bien entendue).

Pour essayé de répondre à ta question prenons un exemple bidon.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
//truc trouvé sur machin.net

//test boucle infini

//voir bug n°123 ligne 6580


//ici plus de memoire physique et virtuelle

//attention algorithme z

//ici c'est coeur du système gaffe !!!!

1-Comment tu documentes cela ?

2-Comment je sais pour qui est-ce que cela est pertinent ?

Ce n'est pas ce que je qualifierais de pertinent.

Ce que j'appelle un commentaire pertinent c'est plutôt quelque chose du style (extrait du code de POCO) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
	DateTime(int year, int month, int day, int hour = 0, int minute = 0, int second = 0, int millisecond = 0, int microsecond = 0);
		/// Creates a DateTime for the given Gregorian date and time.
		///   * year is from 0 to 9999.
		///   * month is from 1 to 12.
		///   * day is from 1 to 31.
		///   * hour is from 0 to 23.
		///   * minute is from 0 to 59.
		///   * second is from 0 to 59.
		///   * millisecond is from 0 to 999.
		///   * microsecond is from 0 to 999.

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

/// Calcule de la racine carré selon l'algorithme d'Heron. Pour plus de details, voir XXXXX

ou, dans le corps d'une fonction, un petit message pour prévenir qu'un code à priori erroné est tout à fait correct pour une raison X ou Y

[Garulfo]

Tout cela me laisse dire que la pertinence ne me semble pas aussi évidente à évaluer. Aussi cela m'étonne qu'un commentaire soit plus pertinent que le code effectif et c'est ce qui me poserait effectivement un problème puisque cela voudrait dire qu'en plus de me taper la lecture du code pour comprendre il faut aussi lire le commentaire..

Ce que tu proposes n'est pas le genre de commentaire dont on parle depuis le début il me semble. Je m'accorde avec GL pour l'avis. Tu oublies un morceau dans tes réflexions il me semble: oui le code auto-documenté est extrêmement important; mais il ne suffit pas. La documentation est une nécessité car elle apporte un élément que le code auto-documenté ne peut apporter : elle explique ce qui doit être fait. Le code lui explique ce qui est fait. La documentation s'écrit avant le code. Ceci permet de guider le développeur pour qu'il respecte les choix du concepteur. En cas de problème, si le code fait bien ce qu'indique les commentaires, l'erreur vient de la conception. Si le code ne fait pas ce qu'indique les commentaires, l'erreur vient du développeur. C'est un apport extrêmement important. Ça augmente la traçabilité des erreurs notamment. Le code auto-documenté nécessite de lire le code. Or on veut aussi pouvoir extraire la documentation du code pour pouvoir la lire sans lire le code. Ce qui amène la nécessité d'une documentation externe. Les outils de génération de documentation sont un atout pour éviter d'avoir un code avec des commentaires qui disent A et une doc avec des commentaires qui disent B. Il me semble que c'est encore une fois un plus. Les désavantages sont faibles comparés aux avantages.

En tout cas, la documentation est nécessaire sous une forme ou une autre. Il me semble que c'est ce qui en sort non ?

La discussion sur les commentaires sort un peu du cadre de la discussion initiale maintenant je trouve.

[hegros]

D'ailleurs l'exemple fourni en Java par un autre contributeur et les discussions autour des commentaires en guise de contrat, pré-condition, post_condition, invariant, etc. tournaient autour de ce type de commentaire.

oui les contrats et invariant c'est un langage formel c'est donc ce qui est le plus exploitable en tout cas par une machine, un humain c'est le doute parce qu'on ne trouve pas forcément tout de suite un intéret parce que verbeux.


Pour le premier exemple de code POCO, à vrai dire je ne le trouve pas pertinent. Il commente ce qui ne va probablement jamais changer. Autant mettre des valeurs par défaut partout ajouter quelques exceptions.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

/// Calcule de la racine carré selon l'algorithme d'Heron. Pour plus de details, voir XXXXX

C'est pertinent cela ? C'est archi connu cette fonction CalculSelonHeron(....) en plus comme cela en brut non connaisseur en algorithme ou en maths alors c'est encore moins pertinent.

ou, dans le corps d'une fonction, un petit message pour prévenir qu'un code à priori erroné est tout à fait correct pour une raison X ou Y

Autant mettre un warning dans ce cas. Si le code est erroné on peut faire confiance au commentaire ? Ce n'est pas ce que j'appelle pertinent ce commentaire mais plutot douteux..

Oui Garulfo c'est une problématique de documentation. Au stade de la programmation notre activité c'est le codage, avec la génération de squelette c'est simplifié on n'a pas le temps de documenter !

Dans les méthodes agiles on a déjà cité XP, UP mais on pourrait aussi parler de Cmmi qui rejoignent aussi le club des limitations de la documentation au niveau du code cela a donc un impact.