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.
- 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. - 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. - 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. - 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.
- 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.
- 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. - 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.
- 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é.
- 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 ? 
Envoyé par sevyc64
