![]() |
Fiche mémo |
Février 2019 |
Documenter son code, c'est déjà travailler pour soi ! Et si quelqu'un d'autre met le nez dans votre création c'est une aide à sa compréhension ! Si vous développez un petit bout de code, il sera absurde de passer autant de temps à la création d'une documentation qu'au développement ! Par contre un professionnel qui va développer un programme dont le code fera l'équivalent de plusieurs ramettes de papier A4 à tout intérêt à passer énormément de temps dans l'analyse du problème et sa documentation. Ce sera un gain de temps pour lui. Pour réaliser cette analyse, il fera appel à des outils que je ne décrirais pas ici. L'idée est plutôt de vous donner de petites pistes pour vous permettre de vous y retrouver quand vous aurez besoin de relire votre code.
Le type de documentation utilisé dans l'exemple ci-contre (CSS) est la base de ce que vous devez faire.
L'utilité de la fonction et ici un exemple d'utilisation de celle-ci sont documentés en entête (avant le code).
Puis sur les lignes qui précisent une action spéciale vous pouvez mettre un texte en bout de ligne.
Remarques : Deux types de langage de programmation existent.
- Les langages "interprétés comme "BASIC" "HTML" "CSS" "php"" qui sont retraduit par le processeur en code compréhensible par lui à chaque exécution.
- Les langages "compilés comme C, C++, PASCAL, COBOL" que la machine va lire une seule fois et créer un code directement compréhensible par la machine.
Alors sachant cela il est évident qui si vous travaillez avec du code interprété, chaque ligne de commentaire va pénaliser (c'est infime mais !) votre programme.
Cela ne veut pas dire que vous ne devez pas documenter votre code écrit en langage interprété (les machines vont tellement vite aujourd'hui !) mais que si
vous avez besoin d'optimiser la vitesse, il peut être nécessaire de faire une deuxième versions du programme en enlevant la doc. (C'est ce que je devrais faire
avec le bout de CSS que je vous ai copié ici !)
Nombreux sont ceux qui aujourd'hui utilisent une base de donnée. Cette base contient plusieurs tables et des relations qui peuvent parfois être
complexes les rassemblent. Cette base forme un tout avec le code qui l'exploite, il est donc important de documenter également cette partie.
L'outil standard est appelé le MCD (Modèle Conceptuel de Données) Je vous invite à bosser le sujet en cas de besoin.
Un outil qui permet également d'éviter de faire n'importe quoi dès qu'une base devient importante est "MERISE" (bonne piste à potasser !)
L'exemple ci-contre compte quelques 200 tables et le MCD prend toute son utilité pour la documentation.
Il existe des méthodes qui facilitent l'analyse d'un projet et qui permettent d'arriver à un résultat fiable, je ne décrirais pas ici ces
méthodes, des bouquins énormes leurs sont consacrés ainsi que de nombreux sites internet. Les mots clés à utiliser pour de l'analyse en
programmation "objet" est "UML" (Unified Modeling Language) et donc "MERISE" pour les bases de données.
Ci-contre en exemple un diagramme des flux.
En UML on vous parlera de "vue fonctionnelle", de "diagramme de classes", de "diagramme d'objet"
ou encore de "diagramme de séquences", si vous pensez qu'un petit dessin vaut mieux que des grands discours cette méthode est faite pour vous !
Même si vous n'utilisez pas une documentation de projet dite "conventionnel" en tant qu'amateur toute documentation
qui vous permettra de vous y retrouver sera la bonne !
J'espère vous avoir donné l'envie de documenter vos programmes et plus important encore faire une analyse de votre projet en amont. Bon courage et n'oubliez pas, vous ne perdez jamais de temps en documentant vos sources !