Les bonnes pratiques en génie Logiciel

En programmation, les « bonnes pratiques » sont le nom donné à des méthodes de travail qui ont fait leur preuve et que les développeurs sont censés connaître et appliquer. Il s'agit d'améliorer la qualité du code, d'en accélérer l'écriture mais aussi d'utiliser des techniques en facilitant la relecture par des personnes étrangères au projet. Si les « bonnes pratiques » du génie logiciel évoluent constamment, celles présentées dans ce document forment un socle sur lequel la plupart des informaticiens s'accordent.

Ce que veut l'utilisateur…

Le point de départ d'un projet repose sur les spécifications données par le client, idéalement de la manière la plus précise possible. Ces spécifications peuvent s'appuyer sur un scénario illustrant comment l'utilisateur du programme comprendra son interface et manipulera les données. Certaines méthodes de travail, dites « agiles », mettent l'accent sur ce type de scénario en étudiant les récits d'utilisateurs (« users stories ») pour expliciter les besoins du client. Ces mêmes méthodes de travail permettent aux spécifications d'évoluer afin d'être améliorées ; c'est ainsi qu'une méthode comme « Scrum » permet de diviser le travail en cycles de développement auxquels le client est étroitement associé. Les spécifications couvrent autant la partie fonctionnelle du projet (comment les données sont-elles modifiées ?) que la partie non fonctionnelle : quelle plate-forme accueille le projet ? dans quel environnement le projet est-il utilisé ? les performances sont-elles importantes ? quelles contraintes la sécurité du projet fait-elle peser ? Quel est le cycle de vie du projet ? Qui en assurera la maintenance ?
Du point de vue de l'utilisateur, le produit fini doit donc allier l'efficacité à l'ergonomie, la puissance à la fiabilité. Comment les développeurs peuvent-ils concilier des exigences aussi contradictoires en couvrant tous les besoins spécifiés par le client et en tenant compte des « users stories » pour améliorer l'utilisation du produit fini ?

… et ce que peut le développeur.

Le développeur est heureusement aidé dans sa tâche par toute une série de « bonnes pratiques » nées de l'expérience acquise depuis les débuts de l'informatique.
Ainsi, écrire le code peut se faire de bien des manières, l'Extreme Programming allant jusqu'à préconiser d'écrire le code à deux. Mais une fois écrit, le code est destiné être relu, soit parce ce que cette relecture fait partie du processus qualité, soit parce qu'un autre développeur aura besoin de le modifier ou de le comprendre. Respecter certaines conventions est donc indispensable.
Il est ainsi admis que la langue de développement doit être l'anglais, tant pour le code que pour sa documentation. Il s'agit de faciliter la communication au sein de la communauté des développeurs mais aussi d'encourager ces derniers à lire et à comprendre le code d'autrui : l'anglais sert donc aujourd'hui de langue de communication. A titre d'exemple, LibreOffice a entrepris un grand « nettoyage » du code d'OpenOffice de manière à en supprimer les commentaires écrits en allemand  qui ralentissaient la relecture du code.
Ce dernier doit également être écrit en respectant des conventions facilitant son écriture et sa lecture. Une fois le langage de programmation fixé, les noms de fonctions et de variables seront écrits en anglais (ex : « .reset() »), en respectant l'alternance des minuscules et des majuscules. Une convention largement répandue consiste ainsi à nommer une fonction imprimant un PDF « .printPDF() » ou « .PrintPDF() » plutôt que « printpdf() », en effet moins lisible.


L'organisation du code répond à des contraintes diverses mais l'élément central reste le principe de la « programmation orientée objet ». Il s'agit de diviser le projet en objets abstraits (des « classes ») contenant des données d'une part, des fonctions d'autre part qui permettent de manipuler ces données. La POO permet de donner une vision plus claire du code et de contribuer à protéger les données contre les modifications intempestives nommées « effets de bord ». Ainsi, plutôt que de modifier directement une variable nommée « image », il peut être intéressant de placer l'image dans une classe et d'ajouter des fonctions .getImage() et .setImage() qui seules permettront de la modifier.
Le code d'un projet est de nos jours conservé sur un serveur faisant fonction de « gestionnaire de projets » et enregistrant de manière incrémentale les modifications apportées au projet. Ce gestionnaire de projets peut être assisté d'un serveur assurant « l'intégration continue » et faisant fonctionner une batterie de tests destinés à vérifier automatiquement la cohérence du projet. Ces tests sont très variés (tests de performance, tests unitaires, tests fonctionnels, …) mais leur efficacité dépend aussi de la manière dont ils couvrent le code. Là encore, des logiciels permettent d'aider les développeurs à repérer les fonctions non testées ou non documentées.
En effet, la qualité de la maintenance dépend directement de celle de la documentation. Celle-ci peut être générée avec l'aide de logiciels spécialisés, tels Sphinx, s'assurant de sa cohérence et de sa mise en forme. La qualité de la documentation peut être régie par des normes ; par exemple il est possible de décider que les commentaires doivent former telle ou telle proportion de la masse totale du code d'un fichier.
Les entreprises qui appliquent ces méthodes sont à la recherche d'une qualité toujours plus grande pour leur projet et cherchent à y intégrer des préconisations valables aussi pour les outils avec lesquelles elles travaillent. C'est bien le cas de Roxecom (e-commerce, e-marketing) qui applique de telles méthodes en les faisant coexister harmonieusement avec des logiciels comme Magento et Drupal.

Les « bonnes pratiques » sont donc nombreuses et il est tentant de les résumer au moyen de quelques grands principes qui ont fait leur preuve. Citons-en deux : le KISS (Keep it Simple) et le DRY (Don’t Repeat Yourself), le premier permettant de ne pas complexifier outre-mesure l'écriture du code, le second s'assurant que rien de redondant n'est écrit.
Respecter les bonnes pratiques n'est donc qu'apparemment contraignant pour les développeurs : en plus d'améliorer la qualité de leur travail, ces pratiques doivent surtout leur rendre la vie plus facile !



 

Ajouter un commentaire

Plain text

  • Aucune balise HTML autorisée.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.
CAPTCHA
This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.
Image CAPTCHA
Enter the characters shown in the image.

Certifié
Magento

Google
Partner

Certification
ceseo 2010

Inscrivez-vous à notre newsletter

Restez au courant de nos dernières nouvelles !

Login

Please login using your credentials recived by email when you register.

I forgot my password | Resend activation e-mail

×