IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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 , par Amine Horseman

36PARTAGES

3  0 
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 ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Laurent 1973
Membre chevronné https://www.developpez.com
Le 05/05/2015 à 10:20
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.
7  0 
Avatar de yahiko
Rédacteur/Modérateur https://www.developpez.com
Le 05/05/2015 à 19:58
Citation Envoyé par Laurent 1973 Voir le message
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 :
5  0 
Avatar de DonQuiche
Expert confirmé https://www.developpez.com
Le 05/05/2015 à 20:14
Citation Envoyé par el_slapper Voir le message
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.
5  0 
Avatar de Bono_BX
Membre confirmé https://www.developpez.com
Le 05/05/2015 à 17:26
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.
4  0 
Avatar de Laurent 1973
Membre chevronné https://www.developpez.com
Le 05/05/2015 à 14:54
Citation Envoyé par sazearte Voir le message
Sa dépend du langage je dirais, prend le c:

Code : Sélectionner tout
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.
4  1 
Avatar de RyzenOC
Inactif https://www.developpez.com
Le 05/05/2015 à 15:01
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
3  0 
Avatar de Washmid
Membre averti https://www.developpez.com
Le 05/05/2015 à 17:02
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.
4  1 
Avatar de bountykiler
Membre régulier https://www.developpez.com
Le 05/05/2015 à 22:34
C'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.

Citation Envoyé par dfiad77pro Voir le message

- 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.
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.

Citation Envoyé par dfiad77pro Voir le message

- 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.
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.

Citation Envoyé par dfiad77pro Voir le message
- L'agile est souvent du faux agile (XP avec 6 intermédiaires avant le métier, faut pas s'étonner que ça échoue )
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.

Citation Envoyé par dfiad77pro Voir le message
Bref les managers ne pensent souvent qu'en terme de coût (je simplifie avec une pincée de mauvaise fois ) .
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...
3  0 
Avatar de RyzenOC
Inactif https://www.developpez.com
Le 06/05/2015 à 14:00
(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 suis clairement pas d'accord, un foreach n'a rien na voir avec un for, quand je fais un foreach je ne mets jamais de i ou de j, je mets des variables explicites.

Je mets des i et des j uniquement dans des "for" et des "while"
3  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 05/05/2015 à 11:58
pour le pair programming, il existe de la littérature qui mesure les couts, mais aussi les bénéfices.
2  0