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
Le 2015-05-05 06:29:50, par Amine Horseman, Expert éminent sénior
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 :
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 ?
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 ?
-
Laurent 1973Membre chevronné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.le 05/05/2015 à 10:20 -
yahikoRédacteur/ModérateurÇ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 :le 05/05/2015 à 19:58 -
DonQuicheExpert confirméJ'adore : tu es la seule personne ici à fournir un lien vers une étude compilant diverses sources empiriques plutôt qu'une opinion et tu te manges un score de -1 !
L'important sur les réseaux sociaux, c'est de brosser dans le sens du poil. Prière de ne pas sortir du cadre.le 05/05/2015 à 20:14 -
Bono_BXMembre confirmé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
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.le 05/05/2015 à 17:26 -
Laurent 1973Membre chevronné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.le 05/05/2015 à 14:54 -
RyzenOCInactifEt en tout cas bien plus que ton nombre "6"
Moi j'ai toujours utiliser des i,j dans mes boucle for/while, j'ai toujours trouvé cela clair, j'ai des mauvaises pratiquele 05/05/2015 à 15:01 -
WashmidMembre avertiJe 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.le 05/05/2015 à 17:02
-
bountykilerMembre régulierC'est quelque chose que l'on voit de plus en plus (il me semble), à savoir remettre en cause tout un ensemble de pratiques que beaucoup de personnes considèrent comme étant "meilleures". Et j'avoue que cette remise en question n'est pas une mauvaise chose en soi.
Je pense que c'est aussi une question de personnalité. Certains vont directement chercher à appliquer le dernier truc à la mode alors que d'autres (comme moi) vont prendre tout cela avec plus de recul. Puis c'est vrai qu'en fonction des personnes, du type de projet et probablement d'autres facteurs ces techniques se révèleront être plus ou moins efficace.
Tiens, perso je suis assez anti-TDD. Pas pour les raisons que tu cites, mais parce que le fait de faire du TDD a tendance à avoir un impact sur le code que l'on va écrire, en ce sens que l'on voudra rendre celui-ci testable. Cela a comme conséquence de rendre le code plus complexe que nécessaire (souvent via l'ajout d'interfaces qui n'ont de sens que dans le contexte du TDD), le rendant du coup plus difficile à maintenir.
Bof. Pour ce que j'en ai pratiqué, cela ne c'est jamais avéré productif. Je sais que beaucoup de personnes ne seront pas d'accord avec moi, mais je vais toujours plus vite quand je travaille seul, sans avoir quelqu'un d'autre à qui je dois expliquer ce que je fais, pourquoi, comment je compte m'y prendre,... Par contre cela peut avoir de l'intéret quand in a une personne + expérimentée qui explique ce qu'elle fait à qqun d'autre.
Ca sent le vécu.
Et là dessus je te dirai que je que assez d'accord avec toi. Bien souvent, les supérieurs hiérarchiques demandent que l'on travaille de manière agile parce que c'est + mieux, mais ne comprennent en rien ce que cela signifie et/ou implique.
Elle est ou la mauvaise fois? C'est juste un fait. Les managers ne pensent qu'en terme de cout et de revenus sans rien comprendre au reste, ce qui abouti en effet souvent à une mauvaise gestion. (en tout cas, cela a été comme cela dans la grande majorité des boites pour lesquelles j'ai déjà travaillé.)
Sinon, pour continuer la liste:
- L’intégration continue
Quasi présent partout ou je suis passé, cela a touours apporté un plus et je n'ai pas d'exemple ou cela a été contre-productif.
- Les design patterns
Oui et non. Attention à bien les appliquer judicieusement, et ne pas chercher à mettre des design pattern pour mettre des design pattern. (j'ai déjà vu cela).
- Le code review
On en fait dans la boite ou je suis actuellement, et cela apporte un plus indéniable.
- Certains ont parlé des conventions d'écriture de code.
Sans vouloir entrer dans un débat sur ce sujet (ce serait bien trop long), il en est une qui est des plus basiques et qui est systématiquement non-respectée par nombre de programmeurs : faites des méthodes courtes!!! Trop souvent, je vois des méthodes qui font plus de 300 lignes de code, ont plusieurs niveaux d'imbrications (4 voir plus), ou contiennent une grande part de code dupliqué. C'est bien là quelque chose que je ne comprendrai jamais...le 05/05/2015 à 22:34 -
RyzenOCInactif(Vous pouvez remplacer le foreach par un for hein c'est juste pour faire un exemple ou le besoin d'utiliser l'index est présent).
Je mets des i et des j uniquement dans des "for" et des "while"le 06/05/2015 à 14:00 -
el_slapperExpert éminent séniorpour le pair programming, il existe de la littérature qui mesure les couts, mais aussi les bénéfices.le 05/05/2015 à 11:58