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

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Débats sur le développement - Le Best Of Discussion :

Quelles pratiques les développeurs devraient-ils éviter ?


Sujet :

Débats sur le développement - Le Best Of

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Mars 2013
    Messages
    8 359
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Administrateur de base de données

    Informations forums :
    Inscription : Mars 2013
    Messages : 8 359
    Points : 195 900
    Points
    195 900
    Par défaut Quelles pratiques les développeurs devraient-ils éviter ?
    Quelles pratiques les développeurs devraient-ils éviter
    pour travailler plus facilement et être plus productifs ?

    Dans cette ère du numérique, les développeurs d’applications sont de plus en plus au centre des grandes avancées technologiques. D’ailleurs les enseignes les plus populaires leur réservent chaque année du temps pour leur présenter leurs dernières nouveautés le temps d’une conférence. Oui, les développeurs et les entreprises technologiques travaillent de concert pour apporter au public les services et produits les plus aboutis qui soient.

    Très souvent, des ouvrages et articles qui visent à aider les développeurs à mieux concevoir leurs logiciels font appels à des expériences positives : conseils pour faire un bon logiciel en C/C++, trucs et astuces pour réussir son application en Java. Mais parfois les retours négatifs peuvent avoir le même effet et permettre aux développeurs d’éviter certains pièges.

    Paul Rubens, ingénieur en sécurité informatique et des réseaux converti dans le journalisme technologique, a énoncé une série de quelques mauvaises pratiques dans le développement à éliminer pour travailler plus facilement et être plus productif.


    1. Les erreurs d’orthographe dans vos codes : selon lui, elles sont assez communes et exaspérantes parce qu’elles n’ont aucun lien direct avec vos compétences en matière de programmation. « Le nom d’une variable ou d’une fonction mal orthographiée peut faire des ravages à votre code. De plus elles (erreurs) peuvent être difficile à repérer » affirme-t-il.

      Dans ce cas de figure il a plusieurs recommandations : travailler dans un bon IDE ou un éditeur de texte spécifiquement pensé pour écrire des programmes pourrait aider à réduire de façon significative les erreurs d’orthographe. Choisir des noms de variables et de fonctions facile à épeler et donc facile à repérer.

    2. Ne pas indenter ou formater son code : l’indentation ou le formatage du code le rende plus facile à la lecture et la compréhension. Par ricochet adopter cette habitude permet d’éviter certaines erreurs mais aussi de rendre la maintenance de votre code par vous-même ou d’autres personnes plus facile.


      Dans le cas où vous utilisez un iDE qui ne formate pas automatiquement votre code, de nombreux outils existent comme Quick Hightlighter (qui formate les codes sources de 85 langages dont ++, PHP, Ruby, HTML, JavaScript, Perl, Python, Smarty, XML), PrettyPrinter (qui offre plusieurs options de formatage selon vos préférences sur de nombreux langages comme PHP, Java, C++, C, Perl ou JavaScript), PHP Code Beautifier, etc.

    3. Ne pas modulariser son code : selon lui, écrire des fonctions qui font une chose et une seule est une bonne pratique. Cela les maintiens courtes et par conséquent facilement compréhensible et donc à maintenir.

      Voici deux règles d’or qu’il propose : une fonction ne doit pas occuper plus d’espace qu’un seul écran et si elle a plus de de 10 boucles ou d’instructions if, alors elle est trop compliquée et devrait être réécrite.

    4. Laisser votre IDE vous procurer un faux sentiment de sécurité : l’un des avantages des IDE se trouve dans la complétion du code ; par exemple, ils sont capables de vous suggérer des variables et autres sur la base de ce que vous avez entré comme informations au préalable. Cependant, l’un des dangers de ces outils est de ne plus prendre le recul nécessaire par exemple en choisissant un élément que l’IDE vous a suggéré parce qu’il ressemble à un élément que vous attendiez. Il arrive que le développeur ne s’assure pas que c’est exactement ce dont il a besoin. L’IDE ne réfléchit pas pour vous, vous êtes entièrement responsables.


    5. Ne pas utiliser un bon chiffrement pour protéger les données : les données critiques doivent être chiffrées parce qu’elles se déplacent sur le réseau et son donc potentiellement exposées à des interceptions chemin faisant. Ce n’est donc pas juste une bonne idée, c’est une nécessité, sinon une loi. Il ne faut donc pas envoyer les données en clair mais se servir d’une librairie standard de chiffrement et l’utiliser correctement. Essayer d’implémenter votre propre système de chiffrement est une tâche très difficile.

    6. Optimiser votre code prématurément : le développeur Donald Knuth, professeur de la matière « The Art of Computer Programming » à l’université de Stanford, a dit une fois « les programmeurs perdent énormément de temps à penser ou à se soucier de la vitesse d’exécution des parties non critiques de leurs programmes et cette recherche de l’efficience a en réalité un impact très négatif lorsque vient le moment de déboguer ou effectuer des maintenances de son code »

      La meilleure stratégie selon Rubens serait d’écrire votre code proprement et de ne retravailler que les parties qui ont vraiment besoin d’être optimisées pour améliorer les performances générales.

    7. Ne pas planifier : même si vous n’avez pas directement des réponses à des questions comme le nombre d’utilisateurs qui va utiliser votre programme, sa vitesse d’exécution et etc., si vous ne parvenez pas d’estimations, comment pourrez-vous choisir le Framework adéquat pour répondre à ces exigences ?

      Twitter est un cas pratique qui peut faire office de bon exemple. Le réseau social a dû abandonner Ruby on Rails et réécrire la plus grosse partie de son code en se servant de Scala et d’autres technologies parce que le code Ruby, dans sa structure d’origine, ne pouvait pas faire face à la croissance exponentielle de la base utilisateurs de Twitter.


    8. Ajouter des personnes à un projet pour combler un retard : en théorie ajouter des personnes à un projet qui prend du retard semble être une bonne idée. Cependant c’est une erreur commune. En réalité, cela conduit très souvent à une baisse globale de la productivité.

    9. Utiliser des mauvaises estimations temporelles : si vous êtes en retard, c’est parce que l’estimation de votre temps est faussée. Cela signifie que vous devez faire une nouvelle estimation de la durée de votre projet et non vous tenir aveuglément à une estimation qui s’est déjà avérée fausse.


    Source : itworld

    Et vous ?

    Qu'en pensez- vous ? Quelles sont les mauvaises habitudes que vous pouvez rajouter à cette liste ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Rédacteur

    Homme Profil pro
    Expert iOS
    Inscrit en
    Juin 2005
    Messages
    413
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Expert iOS

    Informations forums :
    Inscription : Juin 2005
    Messages : 413
    Points : 1 619
    Points
    1 619
    Billets dans le blog
    1
    Par défaut
    Quelles pratiques les développeurs devraient-ils éviter
    Pour travailler plus facilement et être plus productifs ?


    Avoir des clients

  3. #3
    Membre averti
    Profil pro
    Inscrit en
    Octobre 2010
    Messages
    184
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2010
    Messages : 184
    Points : 409
    Points
    409
    Par défaut
    J'ai l'impression d'avoir déjà lu ce genre d'article une bonne centaine de fois, et à chaque fois les conseils de ces experts/journalistes/blogueurs sont d'une banalité et d'une évidence totales...
    Donc oui ce monsieur énonce des bonnes pratiques que tout le monde connais, alors pourquoi relayer une telle info?

    D'ailleurs pour le point 2 qui aujourd’hui qui n'indente pas son code??? Seul point intéressant selon moi qui est parfois négligé par certains dev, c'est le 6, effectivement l'optimisation prématurée est souvent contre productive..

  4. #4
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    Décembre 2011
    Messages
    1 320
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Analyste Programmeur

    Informations forums :
    Inscription : Décembre 2011
    Messages : 1 320
    Points : 3 740
    Points
    3 740
    Billets dans le blog
    12
    Par défaut
    Pour le point n°5 je veux bien comprendre que les données sensibles circulant sur le réseau doivent être chiffrés, mais comment ?
    Si l'utilisateur indique son login/mdp, comment faire en sorte que le mot de passe soit chiffré lors de l'envoi du formulaire vers le serveur ? On ne va pas mettre en place une fonction JS pour chiffrer le mot de passe c'est ridicule.
    N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java

    Ma page Developpez | Mon profil Linkedin | Vous souhaitez me contacter ? Contacter Gokan EKINCI

  5. #5
    Membre averti
    Profil pro
    Inscrit en
    Octobre 2010
    Messages
    184
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2010
    Messages : 184
    Points : 409
    Points
    409
    Par défaut
    Citation Envoyé par Gugelhupf Voir le message
    Pour le point n°5 je veux bien comprendre que les données sensibles circulant sur le réseau doivent être chiffrés, mais comment ?
    Si l'utilisateur indique son login/mdp, comment faire en sorte que le mot de passe soit chiffré lors de l'envoi du formulaire vers le serveur ? On ne va pas mettre en place une fonction JS pour chiffrer le mot de passe c'est ridicule.
    Pourquoi parler de JS? Cet article est généraliste. Si on veut rapporter cette pratique au web on utilisera tout simplement ssl, pour une autre application on pourra utiliser tout algo de crypto asymétrique comme rsa par exemple...

  6. #6
    Membre expérimenté

    Homme Profil pro
    Responsable des études
    Inscrit en
    Mars 2009
    Messages
    553
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Responsable des études
    Secteur : Industrie

    Informations forums :
    Inscription : Mars 2009
    Messages : 553
    Points : 1 672
    Points
    1 672
    Par défaut
    Ces bons conseils sont effectivement vus et revus... Et essentiellement tournés vers le codage. Ca me surprend un peu, car en tant que développeur je passe moins de 50% de mon temps à coder. J'aimerais bien, pour changer, qu'on me donne de bons conseils pour rédiger un cahier des charges, un plan de validation, assurer une bonne couverture de tests, comment passer ISO 9000, que faire ou ne pas faire avant de mettre en ligne une release du produit, comment bien utiliser son gestionnaire de version, ... Du frais, quoi !...

  7. #7
    Modérateur
    Avatar de sevyc64
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Janvier 2007
    Messages
    10 188
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Pyrénées Atlantiques (Aquitaine)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Janvier 2007
    Messages : 10 188
    Points : 28 051
    Points
    28 051
    Par défaut
    Citation Envoyé par miky55 Voir le message
    D'ailleurs pour le point 2 qui aujourd’hui qui n'indente pas son code???
    Malheureusement, beaucoup beaucoup plus de monde que tu ne crois. C'est probablement la raison pour laquelle de plus en plus d'IDE gèrent eux même l'indentation de manière automatique. Avec l'effet pervers que désormais le développeur s'en fiche de plus en plus, alors quand l'IDE perd les pédales dans son indentation c'est encore plus catastrophique.

    Citation Envoyé par miky55 Voir le message
    Seul point intéressant selon moi qui est parfois négligé par certains dev, c'est le 6, effectivement l'optimisation prématurée est souvent contre productive..
    L'optimisation est un mal en soi. Beaucoup de temps perdu pour un gain rarement à la hauteur, beaucoup d'emmerdes en perspectives pour un ROI minable voire négatif. Allez expliquer au client que vous explosez le planning parce que vous tenter de gagner un 1/4 seconde par clic. Le client veut un produit qui marche correctement et livré dans les temps, il saura vous dire s'il perd un 1/4 de seconde en trop sur chaque clic, et là, les choses deviennent négociables

    Citation Envoyé par Gugelhupf Voir le message
    Pour le point n°5 je veux bien comprendre que les données sensibles circulant sur le réseau doivent être chiffrés, mais comment ?
    Si l'utilisateur indique son login/mdp, comment faire en sorte que le mot de passe soit chiffré lors de l'envoi du formulaire vers le serveur ? On ne va pas mettre en place une fonction JS pour chiffrer le mot de passe c'est ridicule.
    L'idée la plus judicieuse ici serait non pas de chiffrer chaque donnée pour la transporter, mais plutôt de chiffrer directement le média, la canal de transport. Par exemple, on ne chiffrera pas le mot de passe d'un formulaire d'identification avant de le renvoyer au serveur, mais on mettra plutôt directement le formulaire sous une connexion chiffrée via https par exemple.

    Citation Envoyé par nnovic Voir le message
    Ces bons conseils sont effectivement vus et revus... Et essentiellement tournés vers le codage. Çà me surprend un peu, car en tant que développeur je passe moins de 50% de mon temps à coder. J'aimerais bien, pour changer, qu'on me donne de bons conseils pour rédiger un cahier des charges, un plan de validation, assurer une bonne couverture de tests, comment passer ISO 9000, que faire ou ne pas faire avant de mettre en ligne une release du produit, comment bien utiliser son gestionnaire de version, ... Du frais, quoi !...
    Juste pour aller au bout des bonnes pratiques, hein :
    - Le cahier des charges, c'est pas au développeur a le rédiger, mais bel et bien au client. Normalement, le client devrait arriver avec son cdc sous le bras en disant "Je veux ça". Oui, je sais, dans el milieu informatique, c'est de plus en plus rare, ça tient plus désormais du miracle ce genre de pratique.
    - Dans un monde de développeur idéal, les tests ne sont pas assurés par le développeur, ni même d'ailleurs écrit, mais par une équipe indépendante du projet et dédié à ces tests. Mais bon, ça aussi c'est très rare. Et puis c'est bien connu, les tests, c'est une perte de temps et puis il n'y a pas mieux placé que le client en production pour faire les vrais tests
    --- Sevyc64 ---

    Parce que le partage est notre force, la connaissance sera notre victoire

  8. #8
    Rédacteur/Modérateur


    Homme Profil pro
    Développeur .NET
    Inscrit en
    Février 2004
    Messages
    19 875
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2004
    Messages : 19 875
    Points : 39 749
    Points
    39 749
    Par défaut
    Pour l'orthographe, c'est vrai que ça m'agace de voir des noms de variables, de classes ou de méthodes mal orthographiés, mais dans les langages à typage statique (C#, Java, C++...) ça n'a généralement pas d'impact sur le bon fonctionnement du code. Par contre dans des langages non compilés c'est une autre histoire...

  9. #9
    Membre habitué
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Décembre 2011
    Messages
    50
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Décembre 2011
    Messages : 50
    Points : 194
    Points
    194
    Par défaut
    un développeur travaillera mieux s'il n'a pas le couteau sous la gorge,

    donc faut éviter toutes les situations de stress :

    - le cahier des charges intenable, irréaliste, 50000 fonctionnalités, le logiciel usine à gaz à réaliser en un temps trop court, le développeur va être tenté de faire du bricolage, de faire du copier-coller de bouts de code qu'il a récupéré en catastrophe sur internet, de bâcler les tests unitaires pour être dans les temps

    - un chef de projet tyrannique ou incompétent

    - une SSII qui maltraite ses développeurs

    - le développeur isolé dans la boite, pas de travail en équipe, pas de possibilité d'entre-aide ou de découpage du travail

    pour tout ce qui est "qualité du code" ( programmation objet, design pattern, MVC, commentaires, indentation ) ça fait partie du métier de développeur, les règles de l'art, comme un artisan qui respecte le travail bien fait, mais malheureusement les circonstances, le contexte ( la compétition acharnée entre SSII, les délais serrés, le budget trop faible ) fait que tout est fait pour que le développeur bâcle son travail,

    la quantité au détriment de la qualité

  10. #10
    Membre éprouvé

    Inscrit en
    Décembre 2009
    Messages
    146
    Détails du profil
    Informations forums :
    Inscription : Décembre 2009
    Messages : 146
    Points : 900
    Points
    900
    Par défaut
    Citation Envoyé par sevyc64 Voir le message
    L'optimisation est un mal en soi. Beaucoup de temps perdu pour un gain rarement à la hauteur, beaucoup d'emmerdes en perspectives pour un ROI minable voire négatif. Allez expliquer au client que vous explosez le planning parce que vous tenter de gagner un 1/4 seconde par clic. Le client veut un produit qui marche correctement et livré dans les temps, il saura vous dire s'il perd un 1/4 de seconde en trop sur chaque clic, et là, les choses deviennent négociables
    Je trouve dommage que tout le monde se foute de l'optimisation. Je test souvent plein de petits jeux sur smartphone, et je trouve catastrophique de voir des jeux qui tournaient sur mon atari 1040, ramer comme c'est pas permis (et ce n'est pas limité au développement indépendant).
    Donc oui, sur un élément de détails, ok on laisse un code qui tourne, et puis un autre, et puis un autre...Woowww là on rajoute une belle image... et on a des bécanes surpuissantes pour faire tourner un traitement de texte et un firefox.

  11. #11
    Expert confirmé Avatar de Zefling
    Homme Profil pro
    Développeur Web
    Inscrit en
    Avril 2007
    Messages
    1 167
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Avril 2007
    Messages : 1 167
    Points : 4 647
    Points
    4 647
    Par défaut
    Citation Envoyé par sevyc64 Voir le message
    Malheureusement, beaucoup beaucoup plus de monde que tu ne crois. C'est probablement la raison pour laquelle de plus en plus d'IDE gèrent eux même l'indentation de manière automatique. Avec l'effet pervers que désormais le développeur s'en fiche de plus en plus, alors quand l'IDE perd les pédales dans son indentation c'est encore plus catastrophique.
    L’indentation automatique casse souvent une mise en forme claire que je m'étais fait chier à faire, alors je ne l'utilise plus, car elle ne peut pas faire du cas par cas. Suivant le contexte, je ne retourne pas à la ligne de la même façon par souci de facilité de lecture, mais ça, l'IDE ne peut pas le savoir.

  12. #12
    Membre à l'essai
    Homme Profil pro
    Inscrit en
    Décembre 2010
    Messages
    49
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France

    Informations forums :
    Inscription : Décembre 2010
    Messages : 49
    Points : 20
    Points
    20
    Par défaut
    L’article est blindé de fautes d’orthographe…

  13. #13
    Débutant
    Profil pro
    Inscrit en
    Mai 2006
    Messages
    688
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2006
    Messages : 688
    Points : 176
    Points
    176
    Par défaut
    Passer un temps excessif à l'écriture de tests unitaires

  14. #14
    Membre expérimenté
    Homme Profil pro
    Développeur Web
    Inscrit en
    Juillet 2009
    Messages
    420
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Juillet 2009
    Messages : 420
    Points : 1 471
    Points
    1 471
    Par défaut
    J'ajouterai que respecter le point 3 facilite grandement la résolution du problème soulevé par le point 1.
    En effet, plus une fonction est réduite à une simple action, plus elle est facile à nommer.

    D'ailleurs, petite parenthèse, si à un moment donné vous êtes tenté de mettre "or" dans le nom d'une fonction ou d'une variable (oui, ça existe, j'en ai vu...) mettez vous sur pause et réfléchissez à ce que vous êtes entrain d'écrire.

    Alors oui, comme certain le "dénoncent" ces conseils sont bateau. Seulement, on rencontre encore très souvent ce genre de problème donc un rappel ne fait jamais de mal.
    N'oubliez pas non plus qu'il y a beaucoup d'étudiants qui traînent sur DVP. Aussi, ce qui paraît évident pour "l'expert confirmé" ne l'est pas forcément pour celui qui démarre.
    Enfin, justement par ce que ces conseils sont bateau... ils nous arrivent quasiment à tous d'en mettre un de côté de temps en temps par ce que bon... "pour cette fois fois, c'est pas très grave" (oui, je vous vois au fond !).

  15. #15
    Membre expérimenté
    Homme Profil pro
    Développeur Web
    Inscrit en
    Juillet 2009
    Messages
    420
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Juillet 2009
    Messages : 420
    Points : 1 471
    Points
    1 471
    Par défaut
    Citation Envoyé par Sylvaner Voir le message
    Donc oui, sur un élément de détails, ok on laisse un code qui tourne, et puis un autre, et puis un autre...
    Justement les impacts de l'effet d'accumulation se voient surtout une fois que chaque partie tourne. A ce moment là, tu va pouvoir optimiser ce qui pose problème.
    Il ne s'agit pas de bannir l'optimisation, mais de ne pas "Optimiser votre code prématurément".

    Le but de l'optimisation ne doit pas être d'utiliser le moins de ressources possible, mais de permettre au système cible (un smartphone, un serveur avec n utilisateurs, n serveurs, etc...) de faire tourner l'application sans broncher.

  16. #16
    Membre actif
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Juin 2011
    Messages
    95
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juin 2011
    Messages : 95
    Points : 264
    Points
    264
    Par défaut
    Qu'en pensez- vous ? Quels sont les mauvaises habitudes que vous pouvez rajouter à cette liste ?
    Aller sur le chat DVP pendant les heures de boulot

  17. #17
    Membre chevronné
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Septembre 2013
    Messages
    485
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Industrie

    Informations forums :
    Inscription : Septembre 2013
    Messages : 485
    Points : 2 151
    Points
    2 151
    Par défaut
    En faite, l'article reprend quelques règles connues sous le nom Anti-Pattern.
    On peux les retrouver ici : http://sourcemaking.com/antipatterns...t-antipatterns

    Il rajoute, à ces bonne pratique de développeur, des bonnes pratiques de management de projet (les 3 dernières règles)
    Pour compléter justement la règle N°8 "Ajouter des personnes à un projet pour combler un retard", je rappellerai "Il n'est pas possible de faire un enfant en 1 mois avec 9 femmes".
    En effet, certaines taches sont incompressibles. Et plus une équipe est grosse, plus la communication en est compliqué.

    Passer un temps excessif à l'écriture de tests unitaires
    Les tests doivent être en effet lié à la sensibilité de tel ou tel bout de code au bug éventuelle.
    Il est plus intéressant de blinder les tests sur une partie d'algorithme métier, que sur des fonctions très basique.
    La fonction d’addition de 2 nombres entiers ne nécessite pas beaucoup de testes
    Inutile aussi de tester des parties de codes reposants essentiellement sur des frameworks ou des librairie externe: on se retrouve à tester ces dernière plus que notre propre code.
    Par contre, à tout nouveau bug trouvé, il est bien de pouvoir y rajouter un nouveau test et de préférence unitaire et automatique: comme ça, on est sur que le bug ne reviendra plus

    Dans un monde de développeur idéal, les tests ne sont pas assurés par le développeur, ni même d'ailleurs écrit, mais par une équipe indépendante du projet et dédié à ces tests. Mais bon, ça aussi c'est très rare. Et puis c'est bien connu, les tests, c'est une perte de temps et puis il n'y a pas mieux placé que le client en production pour faire les vrais tests
    Je suis à moitié d'accord avec cela.
    Je pense au contraire qu'il est important que les développeurs puissent s'impliquer dans les tests.
    En effet, c'est mieux que ce ne soit pas celui qui code une fonction qui doit écrire le teste correspondant, mais rien n’empêche que ce ne soit pas un autre développeur.
    Et puis le TDD prône justement de faire son développement complètement en lien avec ses testes.

    Pour des testes de "release" ou graphique, en effet, c'est mieux que ce soit des gens du métier qui fasse ce type de testes.
    Ils peuvent aussi nous faire remonter des soucis d'ergonomie en plus des bugs.

    En plus, qu'un développeur participe à la campagne de développement de validation d'un logiciel est aussi très formateur pour qu'il comprenne vraiment sa finalité. C'est beaucoup plus facile pour pouvoir se situer quand on ajoute ensuite une nouvelle fonctionnalité.
    En plus, cela permet de faire un lien avec la règle N°6, il peux vraiment se rendre compte des soucis de performance.

    Je conseillerai aussi au développeur d'aller voir chez les clients comment ils utilisent le logiciel.
    Ça peut permettre de se rendre compte du contexte d'utilisation et éviter certain choix pas du tout pratique pour le client.

  18. #18
    Membre régulier
    Inscrit en
    Juin 2010
    Messages
    23
    Détails du profil
    Informations forums :
    Inscription : Juin 2010
    Messages : 23
    Points : 96
    Points
    96
    Par défaut
    Citation Envoyé par Sylvaner Voir le message
    Je trouve dommage que tout le monde se foute de l'optimisation. Je test souvent plein de petits jeux sur smartphone, et je trouve catastrophique de voir des jeux qui tournaient sur mon atari 1040, ramer comme c'est pas permis (et ce n'est pas limité au développement indépendant).
    Donc oui, sur un élément de détails, ok on laisse un code qui tourne, et puis un autre, et puis un autre...Woowww là on rajoute une belle image... et on a des bécanes surpuissantes pour faire tourner un traitement de texte et un firefox.
    Je suis partiellement d'accord avec toi. Oui l'optimisation est importante (je dirais plutôt que ce qui est surtout important c'est de ne pas faire du code hyper gourmand déjà à la base avant de penser à optimiser). Mais en l'occurrence là c'est le contexte qui veut ça, l'optimisation n'est pas un + dans les jeux vidéos, c'est une propriété importante, voire essentielle.
    Tandis que sur un intranet, un back-office ou je ne sais quelle application web non sensible, l'optimisation n'est pas primordiale, l'important c'est que l'application soit fonctionnelle, maintenable et évolutive. L'optimisation trop tôt dans ce genre de contexte, peut être en effet un ennemi et une perte de temps injustifiée.

  19. #19
    Membre averti
    Profil pro
    Inscrit en
    Décembre 2010
    Messages
    126
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2010
    Messages : 126
    Points : 351
    Points
    351
    Par défaut
    Citation Envoyé par Stéphane le calme Voir le message
    [*] Ne pas planifier : même si vous n’avez pas directement des réponses à des questions comme le nombre d’utilisateurs qui va utiliser votre programme, sa vitesse d’exécution et etc., si vous ne parvenez pas d’estimations, comment pourrez-vous choisir le Framework adéquat pour répondre à ces exigences ?

    Twitter est un cas pratique qui peut faire office de bon exemple. Le réseau social a dû abandonner Ruby on Rails et réécrire la plus grosse partie de son code en se servant de Scala et d’autres technologies parce que le code Ruby, dans sa structure d’origine, ne pouvait pas faire face à la croissance exponentielle de la base utilisateurs de Twitter.
    Je trouve l'exemple bien mal choisi. Twitter a du basculé sur scala car ils sont devenu la plateforme de référence mondiale pour le microblogging, le genre de chose ne se planifie pas... Ruby on Rails permet de réaliser des application web de qualitité très rapidement, ce qui leur à permi de conquerir ce marché. Si ils s'étaient focalisé sur la scalabilité dés le départ, ils se seraient surement bien viandé, surtout que ce genre de techno était beaucoup moins mature à l'époque.

  20. #20
    Membre chevronné Avatar de Hellwing
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Avril 2008
    Messages
    538
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Bas Rhin (Alsace)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Avril 2008
    Messages : 538
    Points : 2 089
    Points
    2 089
    Par défaut
    Citation Envoyé par Laurent 1973 Voir le message
    Je pense au contraire qu'il est important que les développeurs puissent s'impliquer dans les tests.
    En effet, c'est mieux que ce ne soit pas celui qui code une fonction qui doit écrire le teste correspondant, mais rien n’empêche que ce ne soit pas un autre développeur.
    Et puis le TDD prône justement de faire son développement complètement en lien avec ses testes.
    Si c'est celui qui a codé qui effectue les tests, il aura un point de vue biaisé, basé sur la manière dont devrait marcher la fonction et se focalisera plus facilement sur ce qui fonctionne et les bugs auxquels il a pensé. Un oeil extérieur sera sans à priori et aura plutôt tendance à trouver des moyens inattendus d'utiliser les fonctionnalités, et donc susceptibles de les faire planter.

    C'est pourquoi dans les équipes avec lesquelles je travaille, je n'hésite pas à demander à mes collègues de tester mes développements et vice-versa.

Discussions similaires

  1. Les développeurs sont-ils des destructeurs d’emploi ?
    Par Hinault Romaric dans le forum Débats sur le développement - Le Best Of
    Réponses: 450
    Dernier message: 09/09/2020, 11h08
  2. Les développeurs détestent-ils les antivirus ?
    Par Hinault Romaric dans le forum Débats sur le développement - Le Best Of
    Réponses: 38
    Dernier message: 30/09/2019, 20h14
  3. Pourquoi les développeurs travaillent-ils la nuit ?
    Par Gordon Fowler dans le forum Humour Informatique
    Réponses: 122
    Dernier message: 06/10/2013, 02h30
  4. Réponses: 17
    Dernier message: 24/02/2012, 12h33
  5. Tous les navigateurs devraient-ils implémenter le protocole HSTS ?
    Par Katleen Erna dans le forum Actualités
    Réponses: 7
    Dernier message: 18/11/2010, 15h05

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo