Le développement correspond à la réalisation concrète de votre projet.
C'est là que vous allez traduire en termes de programmation votre
modèle.
C'est là que vous allez vous confronter à la réalité du code, de la
machine et du système.
Pour partir serein, il est opportun de se mettre dans de bonnes conditions.
La marche-à-suivre proposée ici permet d'avancer suivant un parcours
balisé, je vous invite à la découvrir, thème par thème dans les
sections qui suivent.
Il y a deux excellentes raisons de structurer son projet.
La première, c'est d'y voir clair.
La deuxième, c'est de mettre en place une organisation qui convienne aux
outils qui serviront à l'élaboration de votre logiciel.
Certains d'entre eux exigent une arborescence particulière, d'autres sont
flexibles, il y a pourtant des organisations plus propices à un fonctionnement
ou un autre.
Pour la première finalité, le choix complet vous appartient, c'est à vous de
déterminer l'organisation qui vous convient, en vous laissant guider par ce qui
vous plaît.
La seconde impose ou induit une manière d'organiser les fichiers et les
différentes composantes du logiciel.
A côté de ça, il y a d'autres critères qui interviennent, si je les rassemble
avec les précédents, cela nous donne les ingrédients pour la recette de "la
bonne organisation de votre projet":
- refléter l'architecture telle qu'élaborée pour la "Modélisation et
l'architecture du projet"
- composer une arborescence adaptée à l'environnement et aux outils avec
lesquels votre outil ou ses phases de production auront à interagir
- se mettre en phase avec les usages dans la sphère des développeurs
- faire appel à votre bon sens et votre intuition pour mettre en oeuvre une
organisation qui vous plaise tout en étant compatible avec les critères
ci-dessus
De l'architecture découle une organisation assez évidente: les briques
logicielles identifiées comme modules seront repérées dans l'arobrescence, soit
comme des fichiers, soit comme des répertoires, soit un mélange des deux. Agir
de la sorte permet d'avoir une consistance entre le modèle d'architecture et le
modèle de développement.
C'est un grand pilier de l'art de la programmation: la consistance ou cohérence.
Parmi les critères qui rentrent dans les bons usages des développeurs, il
s'agit de penser déjà en termes d'empaquetage et fourniture. Dans le monde du
logiciel libre, ce paquetage est composé du code source et de la recette
pour construire le logiciel. C'est la base, qui pourra être déclinée de
plusieurs façons, comme nous le verrons plus bas.
Vous glanerez les autres usages en creusant la documentation sur les outils de
développement, en lisant des articles sur les retours de programmeurs, en
interceptant une curiosité sur une IRC ou une mailing-list, en écoutant les
avis des autres, et bien sûr, juste autour de vous, en discutant avec vos
équipes de travail, où que vous soyez.
C'est là qu'il vous faudra faire le tri, entre ce qui marche bien ou pas, ce
qui est esthétique, ce qui est respectueux des standards et usages, sans s'y
enfermer pour autant, et construire progressivement ce qui correspondra à
*votre approche*. C'est un savant mélange, parvenir à cela, sera le fruit de
votre expérience, ce joyau inestimable. Ce joyau sera d'autant plus
resplendissant s'il s'imbrique avec harmonie dans son environnement, comme une
pierre sertie dans un bijou !
Un sacré challenge...
Pour commencer, voilà quelques pistes pour placer les divers éléments
constitutifs de votre projet:
- la documentation:
- un fichier "README", "README.txt" ou "Readme.txt" à la racine du
projet décrit l'essentiel du projet
- un fichier "AUTHORS" reprend la liste des auteurs du projet
(cela évite de les stipuler dans chaque fichier)
- un fichier "LICENSE" reprend le texte de la licence du projet (doit
accompagner le logiciel dans le cas d'un projet GNU)
- un répertoire "doc" ou "docs" contiendra la documentation plus détaillée
- le code trouvera sa place dans un de ces répertoires:
- "src" ou "code": pour tout "code source" constituant le projet, avec une
sous-arborescence par modules
- "lib": contiendra le code source des librairies destinées à ce projet ou d'autres projets
- directement dans un répertoire comportant le nom du module
- Note: Pour Python
- les tests:
- un répertoire "tests" contiendra les tests accompagnant le logiciel
- alternativement, les tests pourront se trouver sous chacun des modules du
projet
- la production (build) et la création de paquetage (packaging):
- Les outils "Makefile" et "configure" pour tout programme compilé
- Un fichier "setup.py" pour une application Python
Les différents éléments seront approfondis dans la section sur "l'empaquetage
et la publication", en particulier les moyens de production et de création de
paquetage.
Pour ce qui est du choix des noms des fichiers, vous êtes invités à consulter
la rubrique "Astuces pour le nommage de fichiers" dans le guide sur les
systèmes Unix.
Concernant la documentation, il y a plusieurs approches.
Par contre, vous avez la liberté de choix: traitement de texte, documentation
en HTML ou pdf, rédigée directement ou générée à partir d'une documentaion en
mode texte. Comme décrit dans la section relative à ce sujet, vous choisissez
"l'outil de documentation qui vous convient".
Au cours du développement d'un logiciel, celui-ci est amené à évoluer. Et cela,
depuis sa conception, jusqu'à sa publication et sa maintenance.
Une fois publié, il est vital de pouvoir identifier avec exactitude chaque
version émise du logiciel. En effet, à partir de ce moment, le logiciel se
retrouve entre les mains des utilisateurs. S'ils ont des questions ou s'ils
tombent sur des erreurs de fonctionnement, il vous faut pouvoir savoir quelle
édition du logiciel est concernée.
C'est le rôle du logiciel de suivi de version. Il en existe plusieurs, un "guide
d'utilisation de git" sera bientôt disponible, qui décrit l'un d'entre eux.
A côté de la version du logiciel proprement dit, c'est tout un ensemble qui est
sujet à cette question: toute la documentation est relative à une version
donnée de l'applicatif. Il est donc nécessaire d'identifier les évolutions dans
la documentation aussi.
Cela peut être fait par le même outil, dans un même dépôt ou non, ou même avec
des outils différents. Ce qui est important, c'est d'établir une correspondance
entre une version de la documentation et une version du logiciel. C'est là
qu'interviennent les étiquettes (tags).
Gérer la documentation au sein du projet permet de renforcer la cohésion entre
les deux. Par contre, il est fréquent que ces deux parties n'évoluent pas en
même temps. Dans ce cas, cela peut être troublant que deux parties qui ne sont
pas en phase se retrouvent publiées au même endroit dans des états
différents. L'idéal est évidemment de faire l'effort de mise-à-jour avant la
publication d'une nouvelle version. Cela peut être facilité si la documentation
est associée au code (certains apprécient, d'autres pas), tel que présenté dans
la "section sur la documentation".
Il y a un autre type d'information qu'il est pertinente associer aux versions
du logiciel: les fiches de suivi (ticket), qu'elles concernent des
dysfonctionnements identififés (bug report: rapports de bogues), ou des
demandes d'amélioration (feature request). Ces fiches permettent de tracer
toute modification du logiciel, et de faire le lien entre le logiciel et la
documentation (la fiche identifie les documents à mettre-à-jour par rapport à
la modification).
Ces fiches peuvent être gérées dans un outil plus ou moins sophistiqué, qui
permet d'établir une correspondance entre les évolutions d'une modification et
l'état de suivi dans la fiche relative à celle-ci.
Dans le monde du logiciel libre, les outils qui prennent en charge à la fois le
suivi de version, des fiches de modifications ainsi que d'autres aides à la
gestion de projet, portent le nom de "forge logicielle". Parmi celles-ci nous
pouvons citer les grandes forges en ligne "github", "gitorious", "bitbucket",
"Savannah", "launchpad", ou celle de "Google". Mais aussi, des applicatifs open
source prêt à installer sur une instance propre: "Savannah" en fait partie,
mais aussi "launchpad", "CodingTeam", "Redmine", ou "Trac".
Vous pouvez choisir d'en utiliser une en ligne, ou vous pouvez décider d'en
installer une par vous-mêmes. Même si vous utilisez la vôtre, il est opportun
d'apprendre à utiliser les forges les plus courantes, de nombreux logiciels
libres sont disponibles sur celles-ci.
Contribuer et interagir avec les projets est un bon moyen d'apprendre à se
servir des outils existants. Ce sera de toute manière un atout pour vous faire
une idée des caractéristiques et des usages, et fort à parier que votre projet
aura à s'intégrer avec d'autres briques répandues sur des moyens distincts !
S'il y a d'excellentes forges en ligne à disposition, et gratuites pour les
projets open source, vous pouvez en effet préférer disposer de votre propre
infrastructure.
L'installation d'une forge est tout de même une aventure d'une certaine ampleur
puisqu'il faut disposer d'un serveur, configuré convenablement.
Ci-après, vous trouverez une approche pour mettre en place à moindre frais quelques
éléments d'une forge. Puisque les produits envisagés sont open source, "à
moindre frais" est à comprendre dans le sens "à moindre effort".
L'idée est de pouvoir partir "tout de suite", tout en disposant déjà d'un filet
de sécurité et en commençant dès le départ son suivi. Sans être freiné par
l'ampleur d'activités préalables au démarrage.... Qui nous tenteraient de
négliger ce suivi.
Puisque dans les suggestions proposées, tout est en mode texte et versionné de
façon consistante, il sera toujours temps de scripter tout ça et d'importer les
informations dans une forge en temps voulu.
Cette idée est inspirée d'un article sur le site web d'ikiwiki, un moteur de
Wiki: https://ikiwiki.info/tips/integrated_issue_tracking_with_ikiwiki/.
La proposition de cet article est d'utiliser ikiwiki pour le suivi des
incidents (issue), en créant une page de Wiki à laquelle sont associés des
tags pour établir des liens entre les pages et créer des rapports en filtrant
sur ces étiquettes.
Eh bien, ce principe pourrait être repris directement dans le dépôt de suivi de
version du logiciel, c'est-à-dire, directement dans l'arborescence du projet.
Evidemment, cette idée a déjà été creusée, comme en témoigne cet excellent
récapitulatif:
http://stackoverflow.com/questions/2186628/textbased-issue-tracker-todo-list-for-git.
Pour notre cas d'étude "fait main", cela consisterait à prévoir un répertoire
"tickets" ou "issues" dans lequel seraient stockées toutes les fiches de
suivi.
La façon la plus simple est d'avoir un fichier texte structuré de façon à
mettre en évidence les champs clés de chaque fiche.
L'idée n'est pas neuve, puisque c'est ce que fait le projet "GNATS", dont la
version 3.103 date déjà de 1997 (aussi loin que remonte l'historique repris
dans le fichier "NEWS.old"): https://www.gnu.org/software/gnats/.
Voici quelques exemples de champs essentiels à prévoir dans une fiche:
- Numéro: numéro de la fiche
- Titre: intitulé de la fiche
- Création: date de création de la fiche
- Version: version vis-à-vis de laquelle la fiche a été levée
- Milestone: version pour laquelle la fiche doit être prise en compte
- Impact: estimation de l'impact sur le logiciel (exemple: anodin, faible,
moyen, fort, critique)
- Etat: où en est le suivi de la fiche (exemple: ouvert, analyse,
réalisation, tests, documentation, suspendu, annulé, clos)
- Description: Description complète de la thématique rapportée (amélioration
ou détection d'erreur)
- Journal: Une entrée datée pour chaque mise-à-jour de la fiche ; dans le cas
d'un traitement par un outil, une partie de cette entrée est gérée
automatiquement pour s'assurer qu'aucune modification ne passe inaperçue
Selon les besoins, vous aurez à enrichir ces champs, mais ils constituent déjà
une bonne base.
Pour l'encodage, vous êtes libre de créer votre format, cependant il peut être
judicieux d'utiliser un format déjà connu et existant comme reStructuredText
(http://docutils.sourceforge.net/rst.html), markdown
(https://daringfireball.net/projects/markdown/syntax) ou le format de la
base-de-données recutils (https://www.gnu.org/software/recutils/).
L'avantage d'utiliser un format connu est que vous vous appuyez sur une
référence, d'autres sont susceptibles de le connaître aussi et vous bénéficiez
des outils qui l'accompagnent. Même si vous n'utilisez pas tout de suite
l'outillage, vous pouvez démarrer comme si c'était un simple fichier texte, et
tirer parti des possibilités offertes par la suite.
Je suggère un fichier par fiche plutôt qu'une seule base-de-données complète,
qui risque de devenir volumineuse et rendrait les recherches à l'aide d'un
éditeur de texte fastidieuses. Et, en se rappelant les "astuces pour le nommage
de fichiers" (voir guide Unix, en cours de rédaction), il sera bon de prévoir
suffisamment de chiffres pour faire face à toutes les fiches susceptibles
d'être émises dans la vie du projet. Avec 5 chiffres, il y a de quoi voir venir !
Prenons pour exemple, la fiche "ticket_00174.txt" au format
reStructuredText, elle pourrait donner ceci:
Mettre au point un outil d'un installation
==========================================
:Numéro: 174
:Version: 0.4
:Milestone: 1.0
:Impact: fort
:Etat: analyse
Description
-----------
Un outil d'installation serait d'une aide précieuse pour les utilisateurs
comme pour les développeurs, il facilitera la maintenance et allégera les
tests de déploiement.
Journal
-------
Réflexion en cours
++++++++++++++++++
:Date: 2015-10-02
Etude de réalisation en cours, il serait bon qu'il soit prêt pour la version
1.0. L'outil d'installation sera une aide au développement aussi car il
allégera les tests de déploiement et facilitera la maintenance.
Champs modifiés:
- Milestone: 1.0
- Etat: analyse
Description à ce jour
~~~~~~~~~~~~~~~~~~~~~
Un outil d'installation serait d'une aide précieuse pour les utilisateurs
comme pour les développeurs, il facilitera la maintenance et allégera les
tests de déploiement.
Création de la fiche
++++++++++++++++++++
:Date: 2015-09-15
Création de la fiche avec l'état suivant:
- Numéro: 174
- Version: 0.4
- Milestone:
- Impact: fort
- Etat: ouvert
Description à ce jour
~~~~~~~~~~~~~~~~~~~~~
Un outil d'installation serait d'une aide précieuse.
Et au format ~recutils~, cela pourrait donner:
Titre: Mettre au point un outil d'un installation
Numéro: 174
Version: 0.4
Milestone: 1.0
Impact: fort
Etat: analyse
Description:
+ Un outil d'installation serait d'une aide précieuse pour les utilisateurs
+ comme pour les développeurs, il facilitera la maintenance et allégera les
+ tests de déploiement.
Journal:
+ [2015-10-02] Réflexion en cours
+ -------------------------------
+
+ Etude de réalisation en cours, il serait bon qu'il soit prêt pour la version
+ 1.0. L'outil d'installation sera une aide au développement aussi car il
+ allégera les tests de déploiement et facilitera la maintenance.
+
+ Champs modifiés:
+ Milestone: 1.0
+ Etat: analyse
+
+ Description à ce jour:
+ Un outil d'installation serait d'une aide précieuse pour les utilisateurs
+ comme pour les développeurs, il facilitera la maintenance et allégera les
+ tests de déploiement.
+
+ [2015-09-15] Création de la fiche
+ ---------------------------------
+
+ Création de la fiche avec l'état suivant:
+ Numéro: 174
+ Version: 0.4
+ Milestone:
+ Impact: fort
+ Etat: ouvert
+
+ Description à ce jour:
+ Un outil d'installation serait d'une aide précieuse.
Dans ces exemples, la traçabilité a été poussée un peu loin pour refléter ce
qui se rencontre fréquemment dans les forges logicielles bien faites.
Les dates de création et de dernière modification n'ont pas été insérées en
tant que champs puisqu'il s'agit respectivement de la dernière date et de la
première date du journal (classé par ordre chronologique inverse, les entrées
plus récentes d'abord).
Evidemment, ce sera vite fastidieux de maintenir à jour autant d'informations à
recopier à la main, ce qui deviendrait rapidement source d'erreur et de négligence.
Deux solutions s'offrent à nous:
- créer quelques outils simples pour aider à la modification d'une fiche
- s'appuyer sur le suivi de version
Pour la première, ce pourrait être une procédure toute simple: garder une copie
de la fiche actuelle, réaliser la mise-à-jour, y décrire la modification pour
le journal et faire passer la nouvelle fiche dans un script qui ajoute au
journal la différence entre l'ancienne et la nouvelle.
Pour la deuxième, c'est tout vu ! Il suffit d'enregistrer chaque changement
au travers du suivi de version. Seule les champs et la notice au journal sont
nécessaires, l'historique des éléments modifiés est directement rendu par
l'historique de version. La fiche s'en retrouve allégée pour une traçabilité
identique !
Au format recutils, la fiche allégée serait (à sa dernière version):
Titre: Mettre au point un outil d'un installation
Numéro: 174
Version: 0.4
Milestone: 1.0
Impact: fort
Etat: analyse
Description:
+ Un outil d'installation serait d'une aide précieuse pour les utilisateurs
+ comme pour les développeurs, il facilitera la maintenance et allégera les
+ tests de déploiement.
Journal:
+ [2015-10-02] Réflexion en cours
+
+ Etude de réalisation en cours, il serait bon qu'il soit prêt pour la version
+ 1.0. L'outil d'installation sera une aide au développement aussi car il
+ allégera les tests de déploiement et facilitera la maintenance.
+
+ [2015-09-15] Création de la fiche
Cela rend tout de suite beaucoup mieux (c'est moins chargé) et convient mieux
au format de recutils qui n'est pas très adéquat pour stocker de longs textes
comme nous l'avons fait précédemment dans le journal.
Pour visualiser les changements entre deux modifications de la fiche, nous
pouvons le faire dans le shell en utilisant l'outil diff. Pour cela,
supposons que vous en ayez gardé une trace sous les noms
"ticket_00174.txt.v0" et "ticket_00174.txt.v1":
$ diff -u1000 ticket_00174.txt.v0 ticket_00174.txt.v1
--- ticket_00174.txt.v0 2015-09-15 18:10:27.332095652 +0200
+++ ticket_00174.txt.v1 2015-10-02 16:58:49.180093194 +0200
@@ -1,10 +1,18 @@
Titre: Mettre au point un outil d'un installation
Numéro: 174
Version: 0.4
-Milestone:
+Milestone: 1.0
Impact: fort
-Etat: ouvert
+Etat: analyse
Description:
-+ Un outil d'installation serait d'une aide précieuse.
++ Un outil d'installation serait d'une aide précieuse pour les utilisateurs
++ comme pour les développeurs, il facilitera la maintenance et allégera les
++ tests de déploiement.
Journal:
++ [2015-10-02] Réflexion en cours
++
++ Etude de réalisation en cours, il serait bon qu'il soit prêt pour la version
++ 1.0. L'outil d'installation sera une aide au développement aussi car il
++ allégera les tests de déploiement et facilitera la maintenance.
++
+ [2015-09-15] Création de la fiche
En passant outre les quelques signes ésotériques (qui ont leur signification),
l'historique des changements se comprend tout seul. En effet, les différences
nous apparaissent tout de suite précédées d'un signe "-" pour ce qui a été
supprimé et d'un signe "+" pour ce qui a été ajouté (note: les signes doubles
"-+" et "++" sont dus à l'artifice de syntaxe utilisé pour décrire un champ
recutils sur plusieurs lignes).
Si vous préférez un affichage côte-à-côte, essayez ainsi:
r3vlibre@artlab:~/tmp/tickets$ diff -y -W 160 ticket_00174.txt.v0 ticket_00174
$ diff -y -W 160 ticket_00174.txt.v0 ticket_00174.txt.v1
Titre: Mettre au point un outil d'un installation Titre: Mettre au point un outil d'un installation
Numéro: 174 Numéro: 174
Version: 0.4 Version: 0.4
Milestone: | Milestone: 1.0
Impact: fort Impact: fort
Etat: ouvert | Etat: analyse
Description: Description:
+ Un outil d'installation serait d'une aide précieuse. | + Un outil d'installation serait d'une aide précieuse pour les utilisateurs
> + comme pour les développeurs, il facilitera la maintenance et allégera les
> + tests de déploiement.
Journal: Journal:
> + [2015-10-02] Réflexion en cours
> +
> + Etude de réalisation en cours, il serait bon qu'il soit prêt pour la versio
> + 1.0. L'outil d'installation sera une aide au développement aussi car il
> + allégera les tests de déploiement et facilitera la maintenance.
> +
+ [2015-09-15] Création de la fiche + [2015-09-15] Création de la fiche
Cette fois, les changements sont repérés par le caractère "|" (appelé pipe)
et les ajouts par le caractère ">" (opérateur de comparaison "strictement
plus grand").
Un avantage du format recutils est qu'il est adapté pour faire des recherches
puisqu'il s'agit d'une base-de-données en mode texte.
Cependant, sans devoir l'installer et apprendre son fonctionnement, vous pouvez
déjà vous débrouiller avec "des outils de base Unix" comme grep et awk.
C'est un réel plus d'apprendre à les utiliser, ils se rencontrent souvent et
peuvent rendre bien des services !
Qui plus est, cette méthode marcherait aussi avec les tickets rédigés au format
reStructuredText au vu de la manière dont nous les avons agencés.
Voyons plutôt:
$ grep -e "Etat: ouvert" tickets/ticket_*.txt
tickets/ticket_00021.txt:Etat: ouvert
tickets/ticket_00044.txt:Etat: ouvert
tickets/ticket_00091.txt:Etat: ouvert
La commande suppose que vous êtes à la racine de votre projet et que vous y
avez stocké quelques fiches dans un répertoire "tickets", en les nommant toujours
bien selon notre exemple.
Pour agir sur plus de critères, il faut passer à un outil un peu plus puissant:
$ awk -v RS="" '/Impact: fort.*Etat: (ouvert|analyse)/ { print FILENAME }' tickets/ticket_*.txt
tickets/ticket_00021.txt
tickets/ticket_00085.txt
tickets/ticket_00174.txt
Le résultat nous donne tous les tickets d'impact "fort", qui sont dans l'état
"ouvert" ou "analyse" (l'ordre des critères est important, il doit correspondre
à l'ordre dans lequel les champs apparaissent dans les fiches, la variable
"RS" assignée à la chaîne vide "" fait en sorte que le fichier soit une
seule entrée).
Pour un résultat plus poussé, il faut encore aller un peu plus loin:
Script shell "tickets.sh"
#! /bin/sh
awk 'BEGIN {
RS="" ;
criteres["Impact"] = "(fort|critique)" ;
criteres["Etat"] = "(ouvert|analyse|réalisation|tests|documentation|suspendu)" ;
}
{
fichiers[FILENAME]++;
for (crit in criteres) {
crit_recherche = crit ": " criteres[crit] ;
if (match($0, crit_recherche, result)) {
criteres_ok[FILENAME,crit] = result[0] ;
}
else {
nb_criteres_nok[FILENAME]++;
}
}
}
END {
for (fic in fichiers) {
if (! nb_criteres_nok[fic]) {
printf "%s",fic "| ";
for (crit in criteres) {
printf "%-20s",criteres_ok[fic,crit];
}
print "";
}
}
}' $*
C'est du awk, un outil très puissant pour manipuler les fichiers contenant du
texte.
Ainsi, l'appel de ce script shell donnera:
$ sh tickets.sh tickets/tickets_*.txt
tickets/ticket_00091.txt| Impact: critique Etat: ouvert
tickets/ticket_00021.txt| Impact: fort Etat: ouvert
tickets/ticket_00174.txt| Impact: fort Etat: analyse
tickets/ticket_00085.txt| Impact: fort Etat: analyse
Voilà, le résultat obtenu est l'inventaire de toutes les fiches d'impact "fort"
ou "critique", qui ne sont pas à l'état "clos" ou "annulé" (tous les autres
états sont valides).
En procédant de la sorte, vous voyez que vous pouvez dès le départ démarrer
votre suivi avec un outillage minimal, sans avoir le besoin de mettre une
infrastructure lourde en place. Il suffit de créer un modèle vide du genre
"ticket_nnnnn.template" pour vous assurer que toutes les fiches auront le
format correct.
En prenant le soin d'associer leur mise-à-jour à chaque modification de code,
votre système est maintenu en cohérence, simplement en vous occupant du suivi
de version (vous pouvez prévoir une branche à part pour ne pas interférer avec
la branche de développement du projet).
A l'avenir, vous pourrez toujours migrer vers une forge logicielle plus
complexe en y important vos données. Ce sera plus ou moins complexe selon les
cas, en tous cas, vous êtes sûr d'avoir toutes les informations depuis la
création du projet.
Tout comme pour les fiches de suivi, il est possible de mettre en place un
suivi de version rudimentaire à condition d'un peu de discipline.
Là, ce sera plus court, car le procédé est assez basique: il s'agit d'utiliser
l'outil tar et encore et toujours les "astuces pour le nommage de fichiers".
Voilà la procédure, il faut commencer par se positionner dans le répertoire du
projet, puis exécuter la commande suivante:
$ tar cfz ~/archives_projets/le-projet_2015-09-16_rev1_tag-optionnel.tgz .
La clé est dans le nommage: les fichiers seront classés par ordre chronologique
grâce au format de la date, et le numéro de révision est donné à titre
indicatif (pour visualiser facilement, à quel stade se trouve la révision).
Dans ce cas, il faut veiller à incrémenter chaque fois de "1" la révision.
Il est à noter que c'est un artifice qui n'est pas nécessaire ou qui peut être
inséré automatiquement.
Un mot clé supplémentaire permet d'attribuer un tag (étiquette) à la
révision. Ce mécanisme est utilisé dans les outils de suivi de version pour
identifier une version particulière, par exemple une révision qui est publiée
officiellement, le numéro d'une fiche de modification qui a été réalisée.
Avec cette méthode, il devient délicat d'attribuer plus d'une étiquette à une
révision, mais c'est déjà pas mal.
Pour construire automatiquement le numéro de révision en considérant qu'une et
une seule sauvegarde a été réalisée pour chaque révision, envisager les
commandes suivantes (à mettre dans un script pour les péréniser):
$ rev=$(ls ~/archives_projets/le-projet_*.tgz|wc -l)
$ rev=$(expr $rev + 1)
$ tar cfz ~/archives_projets/le-projet_2015-09-16-rev${rev}.tgz .
Et pour s'en passer:
$ rev=0 ;
for archive in $(ls ~/archives_projets/le-projet_*.tgz|sort);
do
rev=$(expr $rev + 1) ;
echo "$archive Rev $rev" ;
done
/home/user/archives_projets/le-projet_2015-09-16.tgz Rev 1
/home/user/archives_projets/le-projet_2015-09-17.tgz Rev 2
/home/user/archives_projets/le-projet_2015-09-24.tgz Rev 3
Voilà, c'est loin de fournir les fonctionnalités d'un outil de suivi de
version, mais cette simple précaution vous permet de conserver un historique
complet de votre projet, et de pouvoir revenir en arrière si jamais vous avez
chamboulé trop de choses d'un coup, ou si vous faites une gaffe, ce qui
arrivera sûrement un jour ou l'autre !
Pour aller un cran plus loin, la commande de sauvegarde pourrait être effectuée
par un script qui prendrait un message en argument. Ce message serait stocké
dans un fichier "REVISION" dont la première ligne serait le numéro de
révision, les suivantes le message.
Ce message correspondrait au message de commit des outils de suivi de
version, et vous voyez venir la suite: le jour où vous mettez en place le suivi
de version, vous avez tout l'historique prêt à disposition.
Et quel est le coût ? A peine quelques commandes de shell !
Attention, cette méthode ne sera valable que pour un petit projet, bien sûr. Si
vous êtes plusieurs à travailler, ou si vous travaillez sur un projet
conséquent de plusieurs centaines de fichiers, il est impératif d'utiliser un
outil adapté.
Mais pour démarrer, c'est une bonne manière de prendre le pli dès le début, de
mettre en route une méthode de travail sûre, sans avoir à apprendre tout le
fonctionnement d'un outil.
Et, même le jour où vous aurez un outil spécialisé, sachez que ça peut toujours
être bon de faire une sauvegarde du dépôt, notamment au début, et aussi lors
d'opérations un peu complexes. C'est toujours délicat de rétablir l'état d'un
dépôt, puisque par conception, toutes les étapes sont archivées.
La lisiblité dont il est question ici est la lisibilité du code source d'un
projet.
Pourquoi faire attention à la lisibilité du code source dans un projet ?
Eh bien, s'il a une certaine ampleur ou si, naturellement, il est partagé avec
d'autres, plusieurs personnes vont le lire, plusieurs vont l'écrire.
Un jour vous allez vouloir vous relire, ou lire ce que quelqu'un d'autre a
fait, ou ce quelqu'un d'autre voudra comprendre ce que vous avez voulu faire.
A ce moment, la lisibilité du code prend toute son importance, pour rentrer
dans la compréhension de ce qu'a fait l'autre.
Si du temps a passé après que vous ayez écrit quelque chose, parfois vous aurez
l'impression que vous lisez le code de quelqu'un d'autre.
Dans certains cas, vous aurez un peu de compassion eu égard votre style un peu
imparfait, vous sentirez alors que vous avez progressé. Dans d'autres
circonstances, vous serez surpris: "C'est bien moi qui ai écrit ça ? Comment
j'ai fait ?". Vous étiez inspiré !
Toujours est-il que si ce code est lisible, votre impression en sera meilleure.
Et puis, lorsque vous aller réaliser ou contribuer à un projet, vous allez
écrire du code, vous allez passer du temps dessus, beaucoup de temps.
Il est essentiel que ce temps soit agréable, qu'il vous plaise à être dans ce
code. L'esthétique a son importance. L'esthétique est un des ingrédients qui
fait de la programmation un art.
Enfin, sur un plan concret, si votre code est esthétique, il est plus lisible,
les erreurs sont plus faciles à détecter, les changements et les améliorations
sont plus facile à apporter.
Pour avoir une mesure, repérons les qualités d'un code lisible:
- Le résultat doit être agréable à voir au premier coup d'oeil
- La lecture doit être fluide
- La compréhension doit être facile:
- Idéalement, le code est porteur de sens en lui-même
- Des commentaires expliquent le rôle des parties complexes
Ce sont les critères qui donnent lieu à un code de qualité.
Comment honorer ces critères et obtenir une bonne lisibilité ?
- Réaliser une indentation et aération équilibrée du code
- Faire des choix pertinents dans les noms de variables/fonctions: le code
doit se lire comme un texte
- Maintenir une cohérence dans l'apparence du code
- Eléments syntaxiques: CamelCase, camelCase, under_score, ALL_CAPS
- Une fonction est souvent associée à une action: elle est mise en valeur
par l'usage d'un verbe pour la caractériser
- Mise-en-page des commentaires, des fonctions, de leurs en-têtes
- Aboutir à une modularité réfléchie dont le découpage apporte de la clarté
- Placer des commentaires judicieux (une partie d'entre eux pourra être extraite par des
outils)
- En-tête qui décrit le but du module, du fichier
- En-tête des fonctions: rôle de la fonction et description des entrées/sorties
- Expliciter les parties de code complexes, de sorte que l'on comprenne
de quoi on part avant d'entrer dans cette portion de code et avec quoi
on ressort à la fin. Détailler des étapes intermédiaires si nécessaire.
Avec ça, vous avez de bons points de repères pour rédiger un code esthétique,
de qualité, aisé à parcourir, propice à la maintenance et accueillant pour les
contributeurs.
Avec toute cette préparation, vous êtes fin prêts pour la réalisation !
Il y a une approche que je privilégie pour le développement (en fait,
c'est quelque chose que j'ai appris dans la vie en général), c'est de
commencer petit, à vrai dire "voir loin et commencer petit".
Le préalable, "voir loin", c'est ce que nous avons fait dans le
travail de modélisation.
Appliquée à la phase développement, "commencer petit" pour évoluer
jusqu'au projet à maturité se traduit en quelques règles simples (ou
lignes de conduite pour être plus juste):
- Dès le début, veiller à la lisibilité
- Réaliser à chaque étape une implémentation minimale qui marche
- Enrichir progressivement ce qui existe et a été validé, ajouter le
traitement des cas d'erreur
Le secret réside dans "avoir toujours quelque chose qui marche" et qui
se lit intelligiblement ("veiller à la lisibilité").
"Commencer petit en ayant toujours quelque chose qui marche" revient à
implémenter petit-à-petit les éléments de la modélisation, en se
focalisant sur quelques premières fonctionnalités, en faisant en sorte
qu'elles soient utilisables, même si elles ne remplissent pas
complètement leur rôle.
Pour avoir des fonctionnalités qui marchent sans remplir complètement
leur rôle, elles peuvent être écrites en offrant un comportant
simplifié, en se limitant au cas nominal sans traiter les erreurs
(avec pour condition de validation de ne pas susciter les cas
d'erreur), ou même renvoyer une séquence déterministe, qui soit valide
dans son comportement, et notamment pour les autres fonctions.
Ainsi, son comportement, à ce stade d'implémentation sera valide
vis-à-vis des éléments qui l'entourent et en termes de tests (voir
dans la suite de ce guide). Cela n'implique pas de passer par un
stub (fonctionnalité de remplacement dans les tests), c'est
simplement son stade de maturation qui en est là, à ce moment.
Les tests permettent d'ancrer et de péréniser "ce quelque chose qui
marche", c'est la trace qu'à un moment donné, dans son état,
l'application a donné les résultats attendus, même à un stade de
maturation précoce.
Le suivi de version appliqué aux tests avec leurs résultas de
référence en même temps qu'au code source permet d'associer clairement
quel code a donné satisfaction à quels tests, ce qui est tracé par un
jeu de résultats de référence.
En matière de lisibilité, il va de soi que cette précaution est à
prendre également dans la réalisation des tests.
Le rôle des standards de codage est d'établir uen série de règles pour donner
une direction au style d'écriture pour le code.
Selon les cas, cela peut conduire à des choix heureux ou non.
Mais le principal objectif est de donner une cohérence au projet, donc il est
essentiel de veiller à s'harmoniser avec l'ensemble.
Voilà une execellente synthèse des règles de style pour le codage en Python:
http://docs.python-guide.org/en/latest/writing/style/.
C'est un exemple d'article qui peut vous aider à rehausser la qualité globale
de votre programmation.
Le fait de respecter un standard permet aux développeurs de s'attendre à
trouver une information donnée sous telle ou telle forme, ou à faciliter sa
localisation. C'est quelque chose de précieux.
Si un projet n'a aucune référence de ce genre, tentez de vous harmonisez avec
le code sous la main.
Certaines de ces références existent, tout en étant plus souples en matière de
règles de conduite. Elles vous permettent dès lors plus de liberté dans la
rédaction de votre code ; veillez toutefois toujours à ce que votre production
soit en phase esthétiquement et techniquement avec les choix faits par le
projet.
Cependant, si vous estimez qu'une règle nuit à la qualité ou à la robustesse
d'une impléemntation, vous pouvez toujours le faire valoir. Ce pourra être le
cas pour de jeunes projets. Pour les projets bien pensés et bien établis, ces
aspects-là ont souvent été traités en profondeur.
Bien entendu, rien n'est jamais figé, mais ce qui est sûr, c'est que c'est
votre implication dans un projet qui déterminera la part de poids que vous
pouvez avoir dans son évolution.
Il y a une erreur de communication avec le serveur Booktype. Nous ne savons pas actuellement où est le problème.
Vous devriez rafraîchir la page.