Developpez.com

Club des développeurs et IT pro
Plus de 4 millions de visiteurs uniques par mois

Quelles pratiques les développeurs devraient-ils éviter
Pour travailler plus facilement et être plus productifs ?

Le , par Stéphane le calme, Chroniqueur Actualités
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 ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de chiv chiv - Rédacteur http://www.developpez.com
le 29/06/2014 à 19:40
Quelles pratiques les développeurs devraient-ils éviter
Pour travailler plus facilement et être plus productifs ?


Avoir des clients
Avatar de miky55 miky55 - Membre averti http://www.developpez.com
le 29/06/2014 à 20:04
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..
Avatar de Gugelhupf Gugelhupf - Modérateur http://www.developpez.com
le 29/06/2014 à 20:34
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.
Avatar de miky55 miky55 - Membre averti http://www.developpez.com
le 29/06/2014 à 20:45
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...
Avatar de nnovic nnovic - Membre éprouvé http://www.developpez.com
le 29/06/2014 à 20:49
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 !...
Avatar de sevyc64 sevyc64 - Modérateur http://www.developpez.com
le 29/06/2014 à 21:08
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
Avatar de tomlev tomlev - Rédacteur/Modérateur http://www.developpez.com
le 29/06/2014 à 21:09
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...
Avatar de Potomac Potomac - Membre habitué http://www.developpez.com
le 29/06/2014 à 22:04
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é
Avatar de Sylvaner Sylvaner - Membre éclairé http://www.developpez.com
le 29/06/2014 à 23:14
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.
Avatar de Zefling Zefling - Membre émérite http://www.developpez.com
le 30/06/2014 à 1:15
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.
Offres d'emploi IT
Analyste SI-métier (H/F)
Société Générale - Ile de France - Val-de-Marne
Expert sécurité en audit d'applications (H/F)
Société Générale - Ile de France - Val-de-Marne
Ingénieur sécurité des systèmes d'information drone (2 postes à pourvoir) H/F
Safran - Ile de France - Éragny (95610)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil