sam, 14/11/2009 - 14:07 par Dom
Type:
Sujet:
Les étapes d'un projet bien mené
Le réflexe papier (ou comment réfléchir avant de coder)
Le défaut trop souvent constaté chez les débutants est de se ruer sur son clavier, de prendre le premier compilateur venu et de coder tant bien que mal la première idée qui passe dans la tête. Pour un programme simple, pas vraiment de problème, même si bien souvent le résultat ne sera pas 'optimal'. En revanche, dès que le programme suppose l'usage d'une technologie non encore maîtrisée ou qu'il présente un caractère innovant pour son auteur, les difficultés vont bientôt se faire sentir. Souvent, il faut ajouter un attribut par-ci, une méthode par-là, voir reprendre complètement une classe ou un objet qui a été mal choisis ou trop peu réfléchit. Le réflexe papier, c'est principalement prendre le temps de s'asseoir, souffler, réfléchir et conceptualiser son idée en répondant à ces questions:
Quoi?:
Quelle est exactement mon idée? Déterminer précisément ce que devra faire votre code: ses fonctionnalités, sa finalité.
Qui?:
A qui s'adresse ce code? Quel type d'utilisateur est visé: particuliers, professionnels, débutants ou confirmés? Quelles sont les contraintes du projet: environnement cible (Windows,Linux, embarqué]) technologie imposée [IDLE imposé par l'entreprise?], langage imposé, ...).
Comment?
C'est par cette étape qu'en fonction de ce que le développeur souhaitera réaliser, il poura choisir l'environnement, le langage et la technologie la plus adaptée à son projet. Souvent négligé, ce choix est en réalité primordial. Certains projets n'aboutissent pas uniquement parce que les bons outils n'ont pas été choisis au départ. Il n'est pas possible de faire la même chose en PHP, en C, en .NET, en LISP ou en n'importe quel autre langage! Quoique l'on dise parfois que le C peux tout faire, soyez certains que si autant de paradigmes différents ont été inventés c'est bien pour résoudre plus aisément des problèmes de nature différente. Ne soyez pas fainéant, dites vous qu'il vous faudra peut-être choisir une technologie que vous ne maîtrisez pas encore, voyez-y une occasion en or pour élargir le champ de vos connaissances.
Structurer son projet (ou comment perdre du temps pour en gagner)
L'étape suivante d'un gros projet consiste à le structurer. Le premier travail consiste à le découper en modules, eux-mêmes subdivisés en fonctions élémentaires. Chaque module doit répondre à une et une seule problématique essentielle à votre code. Par exemple: pour construire une voiture, vous auriez les modules carroserie, direction, radio, éclairage, etc. Pour chacun de ces modules, il vous faut ensuite déterminer les fonctions essentielles à son fonctionnement ainsi que les structures qu'il manipule. Le module radio par exemple manipulera de l'électicité faible ampérage: pas besoin de lui fournir des condensateurs pour centrale nucléaire! Ses fonctions de bases seront "allumer la radio", "éteindre la radio", "régler le voume", etc... Cette étape est importante pour pouvoir déterminer avec précision les structures de données à employer. Pas besoin d'une chaîne de 500 caractères pour stocker un prénom: 20 suffirait! Pas la peine non plus d'utiliser une liste chaînée sous prétexte que c'est la dernière structure que vous avez étudiée si un simple tableau suffit.
Chacun des modules déterminés constituera par soucis de clarté un fichier séparé. C'est ce que l'on appelle la programmation modulaire. Pour chaque module, rédigez sur papier la liste des fonctions qui lui sont nécessaires, puis réfléchissez à leurs besoins. Sont-elles public ou private? Quelle est le but de chaque fonction? Pour vous aider à structurer au mieux votre code ou votre site web, n'hésitez pas à utiliser des méthodes de formalismes telle l'UML ou Merise.
Pour les fonctions les plus compliquées pensez d'avance à vos algorithmes. Rédigez-les sur papier en pseudo-code, déroulez-les à la main, calculez leur complexité, vérifiez-les pour toutes les valeurs!
Pour satisfaire à la fois toutes les fonctionnalités et fournir à l'utilisateur un moyen simple de les utiliser, l'interface graphique de votre programme se doit d'être intuitive. Dans beaucoup de cas, une grande partie du code correspond à la gestion et la mise en place de cette interface, aussi, il convient de particulièrement y réfléchir et de la dessiner sur papier. Rappelez-vous: son impact visuel détermine la première impression de l'utilisateur, avant même son utilité et/ou sa qualité. Que ce soit pour un site web ou un logiciel, la clarté et l'intuitivité sont les maîtres mots. Essayez de respecter au maximum la règle des trois-tiers: texte, image, espace libre.
En dernier lieu, que vous programmiez seul ou en équipe, il convient de définir strictement des conventions de programmation que vous suivrez scrupuleusement tout au long de votre projet. Ces conventions vous permettront de vous relire facilement, de structurer votre projet et de lui apporter une unité apprécié des relecteurs. En cas de projet à plusieurs intervenants, les conventions vous permettront d'articuler beaucoup plus facilement les divers éléments ou modules provenant de développeurs différents. Ils permettront également l'unification des codes et de garantir l'unité du résultat final.
Voici un récapitulatif des points à se remémorer:
- Déterminer les modules généraux du programme.
- Découper les modules en fonctions. Une fonction par tâche ou traitement, mais une même tâche peut être découpée en plusieurs fonctions.
- Architecturer vos fonctions entre elles et déterminer l'ordre d'écriture.
- Déterminer les structures et les composants à employer
- Dessiner l'interface graphique
- Déterminer avec grand soin vos conventions pour ce projet
Peser le pour et le contre, mais choisir! (et ne réinventez pas la roue)
Si pour la programmation web le choix est aisé, la multitude des langages de programmation software rend difficile la décision définitive d'un langage et/ou d'une technolgie pour mener à bien un projet. Si de nombreux langages existent, c'est que chacun possède des spécificités intéressantes. A vous de déterminer lequel est utile pour votre projet. Quel est le paradigme le plus adéquat? Y'a-t-il des bibliothèques qui proposent déjà ce que vous souhaitez? Regroupez tous les éléments, les programmes, les manuels qui pourront vous servir, dégrossissez le travail AVANT même d'écrire une ligne de code. Une fois que les choix sont faits, tenez vous-y. Il est malheureusement trop courant de voir des projets stagner car les intervenants modifient les choix de solutions à la première difficulté. Peut-être vous faudra-t-il chercher un moment avant de trouver comment résoudre certains problèmes mais changer systématiquement de langage ou de solution n'est pas la bonne méthode. Au niveau des bibliothèques en revanche il se peut que certaines répondent mieux à vos spécifications que d'autres: renseignez-vous.
Anticipation, structuration et plan d'ensemble sont ici de rigueur:
- Choisir définitivement la technologie et le langage
- Anticiper et commencer à concevoir des solutions
- Choisir les bibliothèques à employer, se former sur les concepts requis
Coder pour l'humain, pas pour la machine
Qu'on se le dise, programmer est typiquement humain, pourquoi alors ne pas prendre en compte celui qui relira votre code? Un ordinateur ne comprend que le binaire. Tout le reste n'est fait que pour l'humain. Programmer en binaire serait vite trop compliqué bien que théoriquement possible. Au début de l'informatique c'était pourtant le cas: les instructions étaient codées en binaire sur des cartes perforées. Avec l'ordinateur numérique et par la volonté de créer des programmes toujours plus complexes, le binaire fut traduit en assembleur. Celui-ci ne se compile pas mais se traduit: chaque instruction n'est qu'un mot mémotechnique plus facile à retenir que son homologue binaire. A partir de là, plusieurs autres langages ont été inventés, ceux-ci sont compilés en assembleur puis traduits en binaire. Là où l'on cherche à en venir, c'est que programmer est déjà fait pour simplifier la vie à l'humain. Pourtant nombre de développeurs semblent avoir oublié cela et indentent mal leur code, ne le commentent pas, utilisent des noms de variables sans significations, ne structurent pas leur projet. C'est moi qui l'ai fait, je le connais! entend-on souvent! Faux: relisez-vous dans une semaine, c'est impossible!
Mais qu'est-ce qu'un code propre? C'est une bonne question, relativement subjective. Selon Robert C. Martin, la seule mesure de la validité d'un code est le nombre de CQCB (C'est Quoi Ce Bordel) qu'un relecteur quelconque prononcera à la lecture de celui-ci. Cette idée est très bonne car effectivement la valeur d'un code ne peut être considérée que vis-à-vis de ses lecteurs. Un bon code sera un code puissant, résolvant parfois des opérations complexes, mais dont la lecture ne nécessite pourtant pas d'effort particulier, d'une part du fait de sa structure finement pensée, d'autres part du fait des commentaires abondants et des noms de variables significatifs.
Rappelons les points importants (pour plus de détail sur chacun des points voir l'article Convention de programmation):
- Structurer son code: utiliser les capacités de programmation modulaire du langage, définir clairement les classes, les méthodes, les fonctions, les disposer dans un ordre compréhensible et logique.
- Ne déclarer les variables que dans les blocs où elles sont pertinentes
- Ne déclarer les variables qu'au moment de leur utilisation
- Eviter la multiplication du code de même utilité: faites une fonction pour la tâche et renommez-là.
- Supprimer les portions de code obsolète.
- Indenter strictement le code.
- Respecter les conventions et les normes; utiliser les mêmes pour la totalité du code d'un même programme.
- Nommer les objets avec des noms clairs et explicites tout en respectant les conventions usuelles.
- Commenter abondamment, clairement et pertinemment votre code.
En dernier lieu, testez, testez et re-testez. Sous toutes les coutures, essayez votre programme et blindez le. Chaque comportement potentiel de l'utilisateur -même et surtout s'il ne va pas dans le sens normal d'utilisation- doit être prévu et anticipé. Afin de tester chaque parcelle de votre programme, utilisez des procédures de tests rigoureux. Pour mieux appréhender la complexité de la tâche de validation d'un logiciel, nous vous conseillons de consulter le document Comment construire les tests d'un logiciel de l'INRS: l'Institut National de Recherche et de Sécurité.
Vous avez aimé ? Offrez-nous le café !
Pas tout compris? Laissez un commentaire ou contactez-nous !
Imprimer
Envoyer
Bug ou erreur ?
