Discussion :

[Amine Horseman]

Que signifie le terme « meilleures pratiques » dans le développement logiciel ?
Un sénior déclare qu'il est dénué de sens et utilisé à tort

Un article publié par Erik Dietrich, blogueur et auteur de deux livres sur le développement, a fait le buzz récemment sur DeadTech. L’article concerne l’utilisation « abusive » du terme « meilleures pratiques » dans les articles et les tutoriels traitant du développement logiciel qu’on peut trouver sur internet.

Selon Erik Dietrich, l’expression « meilleures pratiques » est vague et subjective. En effet, il commence par donner la signification officielle du terme, qu’il décrit comme étant : « la pratique dont la preuve empirique démontre qu’elle est supérieure aux autres pratiques ». Il s’agit là de la définition « idéale » selon Dietrich. La deuxième signification, dite « réelle », la décrit comme étant « une convention sur la manière de faire quelque chose, souvent établie par des organismes de standardisation tels qu’ISO par exemple ».

La troisième définition, celle proposée par Dietrich, la décrit néanmoins comme étant un terme basique et dénué de sens très souvent utilisé par des personnes voulant faire croire que leurs actions sont plus importantes et raisonnables qu’elles ne le sont réellement, et ceci bien sûr sans preuve empirique ou scientifique pour justifier ce choix. En d’autres termes, cette dernière définition, dite « cynique », coïncide avec « l’utilisation la moins crédible » du terme.

« Je suis sûr que je ne suis pas le seul à avoir entendu les gens utiliser le terme "meilleures pratiques" pour justifier leurs actions quand il était clair que cette "pratique" n’a été ni empiriquement démontrée comme étant la meilleure ni approuvée par convention ou par un organisme de normalisation », déclare l’auteur de l’article. Selon lui, ceci peut aussi s’appliquer aux processus industriels. Il donne une liste d’exemples jugés comme étant de bonnes pratiques dans l’industrie des logiciels sans qu’il y ait pour autant de preuves universelles qui démontrent leur supériorité par rapport aux autres pratiques existantes. Parmi cette liste d’exemples, on peut citer :

• Le développement agile
• Le développement dirigé par les tests
• L’intégration continue
• Les design patterns
• Le code review
• Le pair programming

Erik Dietrich insiste sur le fait que ces exemples sont souvent controversés, mais le fait est que l'industrie en général a évolué dans une direction où ces techniques sont largement adoptées. « Il y a une fine ligne entre la sagesse conventionnelle et la fausse idée commune » déclare-t-il. « Comment peut-on savoir si ces pratiques sont vraiment de bonnes idées et, plus important encore, comment peut-on savoir si ces pratiques sont bonnes pour le développeur et pour son organisation ? ».

Source : DeadTech

Et vous ?

Que pensez-vous de l’avis d’Erik Dietrich ?

Les exemples qu’il cite sont-ils de bonnes pratiques ou de simples fausses idées communes ?

[Laurent 1973]

Je considère, pour ma part, que les 7 pratiques évoqués font partie sinon des "meilleures pratiques" de "bonnes pratiques" dans le développement logiciel.
Pour moi, les ayant pratiqués plusieurs fois dans divers projets, je considère que leur pratique empirique m'a démontré qu’elles donnent de meilleurs résultats que de ne pas les utiliser.

Là où je pense que la polémique est présent c'est que dans certain cas elle ne donne pas le résultat escompté par ce qu'on ne les met pas en place complètement: un peu d'agité, un peu de contrôle continue, un peu de TDD, pas trop de pair programming, ....
Ces pratiques nécessite pas mal de changement dans la façon de penser à la fois de la part des développeurs, que du management et parfois, le changement est difficile.
Il peut même s'opposer à des réticences ou des incompatibilité avec des intérêt personnels.

Après, que l'on appelle ça "meilleures pratiques", "bonnes pratiques", "pratiques à la modes" ou "les pratiques d'Erik Dietrich", j'avoue que je trouve ça inutile comme débat et sans grand intérêt.

[el_slapper]

pour le pair programming, il existe de la littérature qui mesure les couts, mais aussi les bénéfices.

[dfiad77pro]

Beaucoup de bonnes pratiques doivent prendre en compte le facteur humain ( ce qui ne ressort jamais dans les stats !).

- Le TDD : c'est sur si on laisse pas le temps au développeur de faire les choses, ça va échouer ! ( ou pire on choisit un dev qui ne sait et ne veut pas savoir ce que c'est qu'un test unitaire)
- Dans beaucoup d'équipes hétérogènes certaines personnes ne savent même pas ce que c'est , et il n'y a souvent pas d'architecte.
- Le développement par pair : si le binôme n'est pas bon ou ne s'entend pas c'est l'échec. Par contre si il s’entendent, ça peut donner de superbes résultats.
- L'agile est souvent du faux agile (XP avec 6 intermédiaires avant le métier, faut pas s'étonner que ça échoue )



Bref les managers ne pensent souvent qu'en terme de coût (je simplifie avec une pincée de mauvaise fois ) donc l’intérêt des méthodes reste très difficile à prouver lorsque la moitié des projets échouent(ou dépassent le budget) à cause d'une mauvaise gestion.

[NSKis]

C'est vraiment le genre de polémique pour mettre un peu d'ambiance à l'heure de l'apéro!!!

Le plus important est de savoir que l'on peut établir toutes les "bonnes", "meilleures" et autres pratiques, la qualité du logiciel dépendra toujours en premier lieu de la qualité et de l'état d'esprit du développeur!!!

Je parle bien d'état d'esprit et pas de diplôme!!! Le développeur doit être réfléchi et METICULEUX, avoir l'esprit du détail...

J'ai ici une pensée émue pour les pseudo-développeurs que certainement tout le monde a eu à subir, de ceux qui, lorsqu'ils doivent corriger un bug, vous retournent un code avec 10 nouveaux bugs qui n'existaient pas avant leur intervention... Et ceux-là vous pouvez leur imposer toutes les bonnes pratiques du monde, ils vous fourniront toujours de la daube...

[RyzenOC]

Que signifie le terme « meilleures pratiques » dans le développement logiciel ?

Celle qui marche (qui ont fait leurs preuves), ainsi que le respect les conventions, par exemple pour les variables, ont ne les nommes pas n'importe comment, i et j son réservé dans les boucles, a b et c dans les calcules arithmétiques...

[Saverok]

Je suis en phase avec le post de Laurent 1973
Si on se mets à débattre sur tous les termes de sémentique marketing, on n'a pas fini et surtout, il ne nous resterai plus de temps pour développer et les mettre en pratique justement lol

[yahiko]

Même si ce n'est pas très politiquement correct, la racine des problèmes de l'IT ce ne sont pas la sémantique autour des bonnes ou des mauvaises pratiques, mais c'est d'abord les bons développeurs et les mauvais développeurs, dans le sens de compétents, organisés et rigoureux.

Les bonnes pratiques n'étant finalement que des sparadraps pour limiter la nuisance causée par les mauvais développeurs.

Au fur et à mesure que le métier de développeur se démocratise, on a tendance à invoquer ces bonnes pratiques alors que le problème est ailleurs.

[Laurent 1973]

.. comment, i et j son réservé dans les boucles, a b et c dans les calcules arithmétiques...

Je suis d'accord sur avoir des conventions de nommages, c'est une bonne pratique en effet.
Mais pour moi, je m'interdis les variables de moins de 3 caractères qui n'ont pas la signification de ce qu'elles contiennent.

Pour une boucle ce sera plutôt "truc_index" et "machin_index" que i et j (voir k, l, m, n ... on en finit plus).
Au moins, quand on reviens dans le code, on comprends plus facilement à quoi correspond chaque index de boucle.

Pour information: dans beaucoup de langages, la longueur maximum d'une variable et d'une fonction c'est 255 caractères, alors on peux être explicite et éviter les abréviations incompréhensibles.

Donc, désolé, mais utiliser i, j, a, b, c ... n'est pas pour moi une bonne pratique.
Comme quoi la notion de bonnes pratiques est subjective aussi.

Tiens, a ce propos, 2 "bonnes" pratiques que je rajoute souvent dans mes projets informatiques:
- aucun warning en compilation
- utilisation d'un outil d'analyse statique de code (comme lint en C++) avec zéro erreur à l’intégration continue

[tomlev]

• Le développement agile
• Le développement dirigé par les tests
• L’intégration continue
• Les design patterns
• Le code review
• Le pair programming

Dans le tas j'en vois quand même plusieurs qui contribuent indubitablement à la qualité du code :

• design patterns : ce n'est pas pour rien qu'on appelle ça des patterns, ce sont des solutions éprouvées pour résoudre certaines classes de problèmes. A condition de les utiliser avec discernement, ça ne peut être que bénéfique.
• code review : dans ma boite, on est longtemps passé à côté ; maintenant qu'on le fait régulièrement, 95% des code reviews permettent d'identifier en amont des problèmes qui se seraient peut-être révélés beaucoup plus tard autrement.
• intégration continue : c'est clairement un des meilleurs moyens de s'assurer qu'on ne commite pas n'importe quoi...

Pour le reste, c'est plus des questions d'opinion. Par exemple la méthode Agile a ses avantages, mais ce n'est sans doute pas une "bonne pratique" dans le sens où il faut obligatoirement le faire.

[RyzenOC]

Pour une boucle ce sera plutôt "truc_index" et "machin_index" que i et j (voir k, l, m, n ... on en finit plus).
Au moins, quand on reviens dans le code, on comprends plus facilement à quoi correspond chaque index de boucle.

Sa dépend du langage je dirais, prend le c:

Code :

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

1
2
3
4
for (i=1; i<6; i++) {
 printf("%d", i);

}

Je n'ai jamais vu de

Code :

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

1
2
3
4
for (nombredepointeurdansmonobjetdemonprogrammesouslinux=1; nombredepointeurdansmonobjetdemonprogrammesouslinux<nombredepointeurquejedoismettrepourquesamarche; nombredepointeurdansmonobjetdemonprogrammesouslinux++) {
 printf("%d", nombredepointeurdansmonobjetdemonprogrammesouslinux);

}

C'est beau 255 caractère dans une variable , je reconnais je suis de mauvaise foi.
Dans mon premier exemple, tu peut remplacer 6 par un nom explicite, mais je vois l’intérêt de remplacer i par autre chose ?

[Laurent 1973]

Sa dépend du langage je dirais, prend le c:

Code :

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

1
2
3
4
for (i=1; i<6; i++) {
 printf("%d", i);

}

C'est très jolie ta petite boucle.
Mais à quoi correspond chaque itération de celle ci? un temps? la tentative d'une action qui peux échoué? une parcours dans une liste?
De plus "6", numéro magique qui tombe comme un cheveux dans la soupe: privilégier l'utilisation d'une constante explicitant le sens de ce "6"

Sinon, je trouve que "index_du_pointeurs_dans_mon_objet_de_mon_programme_sous_linux" et "nombre_de_pointeurs_que_je_dois_mettre_pour_que_ca_marche" sont plus lisible que "nombredepointeurdansmonobjetdemonprogrammesouslinux" et "nombredepointeurquejedoismettrepourquesamarche" mais chacun ses goûts .
Et en tout cas bien plus que ton nombre "6"

Et c'est pas parce que l'on utilise i, j, k dans les boucles depuis 40 ans (à une époque où les variables étaient limité à 8 caractères) que c'est une bonne chose.

Bon, je suis aussi un peu de mauvaise foi au sens que je n'utilise jamais 255 caractères pour nommer une variables.
Mais entre 10 et 30 c'est assez classique et cela m'évite de rajouter un commentaire pour expliquer son rôle.

[RyzenOC]

Et en tout cas bien plus que ton nombre "6"

J'ai préciser que le nombre 6 doit être une variable explicite.

Moi j'ai toujours utiliser des i,j dans mes boucle for/while, j'ai toujours trouvé cela clair, j'ai des mauvaises pratique

[redbullch]

Donc, désolé, mais utiliser i, j, a, b, c ... n'est pas pour moi une bonne pratique.

C'est aux mathématiciens qu'il faut expliquer ça

[Laurent 1973]

Moi j'ai toujours utiliser des i,j dans mes boucle for/while, j'ai toujours trouvé cela clair, j'ai des mauvaises pratique

Je ne dirais pas que tu as de mauvaises pratiques, mais par contre je considère que ce type de convention n'est pas vraiment une "bonne" pratique à donner en exemple (tu vois la nuance)
Au moins, tu as conscience que les conventions ne nommage est une bonne pratique et je suis d'accord avec toi.

Ensuite, si toi ou tes collègues n'avez jamais eu de souci de compréhension (sans mélanger i et j dans 2 boucles imbriqués complexe) d'un vieux code utilisant cette convention, pourquoi changer en effet.
Les conventions sont parfois dépendant de l'organisation, du projet et des technologies utilisées.

Je ne souhait pas conclure que tout ce qui n'est pas une bonne pratique, doit forcément être une mauvaise.
On est humain et contrairement au machine, tout n'est pas binaire dans notre perception.

[Saverok]

Moi j'ai toujours utiliser des i,j dans mes boucle for/while, j'ai toujours trouvé cela clair, j'ai des mauvaises pratique

Sans aller jusqu'à dire que c'est une "mauvaise" pratique
On peut dire qu'elle n'est pas optimum

Dans le billet de blog d'Erik Dietrich, il n'est pas question de bonnes ou mauvaises pratiques mais de l'utilisation du terme "meilleures" pratiques
Je conviens que techniquement et mathématiquement, le nuance est de taille
Mais en ce qui concerne l'expression orale, je trouve que c'est se prendre la tête pour pas grand chose

[Washmid]

Je dirais que dans un contexte de "bonne pratique", la question du i,j,k,l etc. ne se pose même pas, parce que 3+ boucles imbriquées dans une méthode est un sérieux indicateur comme quoi il est nécessaire de découper un peu plus son code.

[Bono_BX]

Tiens, a ce propos, 2 "bonnes" pratiques que je rajoute souvent dans mes projets informatiques:
- aucun warning en compilation
- utilisation d'un outil d'analyse statique de code (comme lint en C++) avec zéro erreur à l’intégration continue

Ton post m'émeut

Je suis dans une mission où je désespère de faire accepter les bonnes pratiques que tu sites (en particulier la seconde), ainsi que de simples règles ... de bon sens.
Impossible de faire comprendre l'intérêt d'avoir du code bien indenté, même quand le moteur de l'application est illisible, et que du coup personne ne sait comment il fonctionne ...
Et bien sûr, quand j'ai remis de l'ordre là-dedans, j'ai eu beau livrer mes modifications régulièrement, personne n'a fait d'update fréquent. Résultat, au moment de la livraison : "Ho mais c'est le bazar, c'est tout rouge dans l'outil de merge !"
Et au lieu de faire les fusions correctement, les collègues ont fait ... des revert à l'arrache sans analyse d'impact !
Bonjour les bugs et les régressions !

Bref, comme dit précédemment, ces bonnes pratiques dépendent beaucoup des développeurs.

[marsupial]

Si j'ai bien tout compris, et dites moi si je suis hors-sujet, mais l'erreur générée en cas d'utilisation sans redémarrage des Boeing tous les 248 jours minimum provient d'un manque de prévoyance ou d'une incapacité pour cause de brevets logiciels à faire mieux ?

Ceci est une pure question informative.

[yahiko]

Tiens, a ce propos, 2 "bonnes" pratiques que je rajoute souvent dans mes projets informatiques:
- aucun warning en compilation

Ça me rappelle une anecdote qui avec le recul est plutôt amusante, lorsque j'ai eu à récupérer un jour une base de code d'un collègue. Je compile et le log inondé de warnings...

Moi au collègue : Hmmm... Il y a comme un souci... Tu vois tous ces warnings ?
Collègue : Oui et alors ?
Moi : Ben, il faut les supprimer.
Collègue : Fastoche ! C'est juste une option du compilateur à cocher !
Moi :