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 !

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

Le , par Stéphane le calme

22PARTAGES

7  6 
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 ?

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

Avatar de miky55
Membre averti https://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..
11  0 
Avatar de Sylvaner
Membre éclairé https://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.
10  0 
Avatar de chiv
Rédacteur https://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
7  0 
Avatar de nnovic
Membre expérimenté https://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 !...
8  2 
Avatar de Beowulf59
Membre actif https://www.developpez.com
Le 30/06/2014 à 9:15
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
6  0 
Avatar de miky55
Membre averti https://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...
5  0 
Avatar de Xinu2010
Membre averti https://www.developpez.com
Le 30/06/2014 à 11:16
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.
4  0 
Avatar de tomlev
Rédacteur/Modérateur https://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...
6  3 
Avatar de Potomac
Membre habitué https://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é
4  1 
Avatar de skypers
Membre à l'essai https://www.developpez.com
Le 30/06/2014 à 8:51
L’article est blindé de fautes d’orthographe…
3  0