Un Electron Libre...

Je vais lancer une série "Intégration" dans laquelle je vais parler de points vue dans mon quotidien ou dans mon passé en SSII.

Cela faisait un moment que je voulais écrire ce billet, convaincu de plus en plus que le cahier de recette devient un élément de plus en plus crucial dans un projet informatique.

Idéalement, je vois une première version réalisée à l'issue de la phase des spécifications. Sans aller parler de "Test Driven Development" (Développement piloté par les tests, qui l'on peut résumer synthétiquement par le fait d'écrire les tests avant de coder quoi que ce soit), l'idée de rédiger le cahier de tests à l'issue de la phase de spécifications a tout son sens selon moi. Rédiger le cahier de recette (technique et/ou fonctionnel) à cette étape apporte les avantages suivants :

• Cela permet de consigner par écrit ce qui semble parfois "tellement évident" à certains membres du projet et qui peut ne pas l'être pour d'autres ou bien pas si évident que cela (périmètre de tests, éléments à tester, conditions de tests, etc).
• On peut s'apercevoir qu'il y a des manques dans les spécifications que l'on peut alors enrichir (règles de gestion, cas non imaginés de premier abord, etc) : imaginons par ex un intranet groupe avec une authentification intégrée, par défaut, on imagine très bien le cas du français se connectant sur l'application depuis son poste france, mais que se passe-t-il s'il se déplace dans une filliale pour laquelle l'authentification intégrée n'est pas en place ? L'utilisateur pourra-t-il se connecter malgré tout à l'application ?).
• Dans le cas d'une relation avec un prestataire, cela évite les mauvaises surprises en phase de recette (le cas de recette 12, pourtant tellement évident coté client et absolument pas (pré)vu par le prestataire)
• A l'issue de la phase de développement, vous pouvez demander au prestataire de vous indiquer le résultat de sa recette vis à vis de ce cahier de recette (qui aura pu être complété/détaillé entre temps).
• Lors de la phase de recette, vous avez un référentiel sur lequel peut s'appuyer votre démarche de recette.

En tout état de cause, il est important de faire vivre votre cahier de recette : de test très macro (état initial > étapes > résultat) réalisés dans un premier temps, vous pourrez le compléter (nouveaux cas) ou bien le détailler/préciser ou encore définir des "sous-cas" de tests.

Il est également important de communiquer ce cahier de recette aux parties impliquées pour avoir leur réaction et échanger. Cela peut le cas échéant donner lieu à des avenants/aménagements des phases de développement (cas d'évolution). Le fait que ce soit dans votre cahier de recette ne veut pas forcément dire qu'il doit être accepté systématiquement par votre équipe de développement / prestataire ; en effet, si cela n'est pas dans le périmètre de départ ou a un impact trop significatif sur les développements, il vous faudra en discuter (c'est sur qu'en cas d'engagement au forfait...)

Pour être honnête, moi même en SSII, j'ai très peu appliqué cette méthode - seulement lors de mes dernières missions en AMOA lorsque j'étais en SSII ou pour un projet interne actuel chez mon actuel employeur. Dernièrement, lors d'un POC (Proof Of Concept / Prototype), j'avoue avoir été étonné que personne ne s'en est pré-occupé avant que j'en fournisse un - permettant d'ailleurs de découvrir le cas du français en déplacement dans une autre filliale par ex. Tout le monde savait qu'il fallait tester deux fonctions "authentification" et "indexation" et il a bien été démontré que cette soit-disant évidence des tests n'allait pas de soit sur de nombreux sujets ou tout bonnement sur le périmètre même du POC.

La seule explication au fait que cela ne soit pas plus utilisé à présent dans les méthodes de développement est un temps de spécification mal estimé conduisant à ce qu'il soit négligé / repoussé à la phase de tests. Vous en voyez d'autres (bonnes|mauvaises) raisons ?

Je viens de finir la lecture de Practical Django Projects, écrit par James Bennett, qui occupe le poste de "Django Release Manager" et qui a publié sur son blog de nombreux billets sur Django et les bonnes pratiques à avoir/appliquer. Autant le dire tout de suite, le livre est de la même qualité que ses billets : accessibles, pédagogiques et pertinents.

Le livre se décompose en cinq grandes sections :

• Présentation de Django
• Réalisation d'un CMS simple (permettant de poser les bases)
• Réalisation d'un weblog (permettant de découvrir les concepts de "template tags", manager, l'utilisation de librairies tiers, les vues génériques, etc)
• Réalisation d'un dépôt de code (qui complète les points abordés précédemment et permet d'aborder le gestionnaire de formulaires).
• Synthèse sur les bonnes pratiques à suivre pour du code flexible, adaptable, réutilisable, distribuable et surtout documenté !

Autant je n'ai pas appris grand chose avec les deux premières sections, autant j'ai adoré la troisième et cinquième. Pour la quatrième section, mon niveau en python & django font que pas mal de choses me sont passées pour le moment au dessus de la tête et que cela ne répond pas à mes besoins immédiats (contrairement à la troisième section).

Même si l'arrivée de la nouvelle interface d'administration et le fait que le code sur les "Signals" ait été réécrit font que quelques infimes parties du livre se trouvent aujourd'hui un peu obsolètes, le livre a le grand mérite de tout bien expliquer, de poser les bases et d'accompagner le lecteur dans une montée en puissance au niveau de sa maîtrise de Django.

Le seul reproche que je peux formuler concerne la quatrième section où l'accent n'est mis que sur les nouveautés. Du coup, on appréhende moins la construction de l'application en tant que telle. A ce jour le code source utilisé dans le livre (section de gauche) n'étant pas encore dispo sur le site d'Apress, cela n'aide pas non plus pour prendre le train en route...

Pour tout ce qui est bonnes pratiques, elles sont présentes partout dans le livre. Point besoin d'attendre la 5ème section pour en bénéficier. L'auteur prend même au début le plaisir à montrer la "mauvaise façon" (ie sans prendre en compte les besoins d'extensibilité/flexibilité/...) puis montre ensuite la "bonne façon" de faire. Des conseils qui sont en général assez simple à suivre et donne de solides avantages au code généré (lisibilité, simplicité, réutilisabilité, etc).

(Mal)heureusement, je n'avais pas de PC sous la main pour coder en parallèle. Je n'ai donc pas pu capitaliser / jouer avec ce qui a été abordé. (J'aurais en outre pu en profiter pour coder la base de mon projet Atome...)

Pour conclure, si quelqu'un souhaite se mettre aujourd'hui à Django, je ne saurais trop lui recommander de lire en premier lieu "The definitive guide to Django : web development done right" puis ce livre ensuite. Avec ça et ensuite la documentation en ligne, il est prêt pour mener à bien des projets (perso/pro).

Quand j'ai vu cette chaine sur les conventions de codage se diffuser sur le web avant l'été (ici ou encore là), je me disais "enfin une qui va me passer à coté, je peux dormir tranquille", ne me considérant pas comme un développeur (ou alors un du dimanche ) et n'étant pas non plus développeur de formation... Et bien non, Nicolas Hoizey a décidé de me refiler cette chaine.

Pour les projets réalisés dans un cadre professionnel, pour tout ce qui a été en html/css/php et autres boucles SPIP, j'ai par le passé tenté de bêtement copier ce que faisaient mes petits camarades. Cela se justifiait principalement par le fait que j'intervenais ponctuellement sur le code et ne souhaitait pas les perturber plus que nécessaire.

Pour les projets réalisés dans un cadre professionnel et dont je suis à l'origine ou pour mes projets perso, je n'ai pas de règle précise, je vise surtout une logique de lisibilté.

Cela donnera par ex pour un script bash dont l'objectif est de packager des fichiers par ex :

#
## Get relevant information for the packaging
#
 
# Do we need to send file on the front server ?
... some code ...
 
# Do we need to send file on the database server ?
... some code ...
 
#
## Let's build the package
#
 
# Package files for front server
... some code ...
 
# Package files for database server
... some code ...

Je prends souvent ce schéma pour tout ce qui a trait à l'administration système et pour les CSS (en adaptant les caractères de commentaires bien sur...).

Pour continuer sur les CSS, mon ordre de fabrication de mon fichier va être le suivant :

• Eléments globaux / génériques
• Section des plus "grandes" vers les plus "petites" (body > left > sidebar)
• Au sein de chaque section, en premier lieux les éléments de positionnement puis ceux de mise en forme (pour reprendre une logique du plus grand au plus petit)

L'idée étant de regrouper le code en des sous-ensemble logiques.

Cela pourrait donner qqc comme :

/********************************
*  Elements généraux/generiques
********************************/
 
body {
}
 
h1 {
}
 
a {
}
 
/********************************
* Zone gauche
********************************/
 
#left {
}
 
/* Menu gauche */
 
#left #menu {
}
 
#left #menu a{
}

Par contre, là où j'ai toujours eu un souci avec PHP par ex, c'est sur la convention à suivre sur la gestion des accolades (qui en plus suivant l'IDE, l'interpréation peut changer) :

Ex :

if ($toto == "toto")
    {
    ... some code ...
    }

ou

if ($toto == "toto")
{
    ... some code ...
}

ou :

if ($toto == "toto") {
    ... some code ...
    }

ou :

if ($toto == "toto") {
    ... some code ...
}

Ou surement encore plein d'autres choses faisant que mon code au final se trouvait mal indenté (ou pas toujours de la même façon, ne parvenant pas à décider de ce qui était le plus lisible), surtout si les choses avaient tendance à s'imbriquer.

Je pense d'ailleurs que c'est une des raisons pour lesquelles j'aime python. L'indentation que l'on doit respecter permet de donner une bonne lisibilité du code. En plus, la charte de bonne conduite est clairement définie, même si je ne la suis pas encore dans son intégralité...

"""
Profile
 
This object is used to provide some common information regarding the profile of a user.
"""
 
class Profile(models.Model):
    CIVILITY_CHOICES = (
         ('single', _('Single')),
         ('taken', _('Taken')),
    )
    who = models.ForeignKey(User, unique=True, verbose_name=_('Person'),)
    photo = models.ImageField(height_field="80", width_field="80", upload_to="photos", blank=True)
    street = models.CharField(_('Address 1'), max_length=100)
    street_bis = models.CharField(_('Address 2'), max_length=100, blank=True)
    zipcode = models.IntegerField(_('Zip code'), max_length=5)
    city = models.CharField(_('City'), max_length=100)
    country = models.CharField(_('Country'), max_length=100)
    phone = models.CharField(_('Phone'), max_length=20)
    mobile = models.CharField(_('Mobile'), max_length=20, blank=True)
    civility = models.CharField(_('Status'), max_length=20, choices=CIVILITY_CHOICES)
    birthdate = models.DateField(_('Birth date'))
    children = models.IntegerField(_('Children'), blank=True, null=True)
 
    def __unicode__(self):
        return self.who.get_full_name()
 
    class Admin:
        list_display = ('who',)
        list_filter = ['who',]
        search_fields = ['who',]
 
    class Meta:
        verbose_name = _('Civil state')
        verbose_name_plural = _('Civil states')

Pour le débat indentation vs espace, j'avoue avoir préféré les espaces. Etant feinéant, je profitais aussi de la fonction de nombreux IDE qui transforment la tabulation en 4 espaces (ce qui permettait de continuer à utiliser la touche tab pour indenter son code...)

En tous cas, si je devais donner une conclusion à cet essai, que pour adopter une convention de codage, il faut :

• Regarder si une convention n'est pas définie au niveau du language, si oui, alors l'adopter.
• Regarder si une convention n'est pas définie au niveau du programme que vous utilisez, si oui, alors l'adopter (et si elle entre en conflit avec celle du langue, tant pis pour le langage, il est plus logique d'avoir un code cohérent)
• Si aucune des deux n'est définie, voir pour trouver une convention qui vous va bien à vous et le cas échéant à vos coéquipiers (à ce titre, mieux vaut en discuter avant le début du code qu'après, ça évitera de vous marcher dessus ensuite...)
• Adopter une terminologie anglaise (penser que votre code et commentaires peuvent être lus/utilisés par un prestataire indien - que feriez vous si vous deviez reprendre un code dont les commentaires sont en chinois par ex ?)

Le framework Django, vient de sortir en version 1.0 alpha, premier jalon d'une série de release devant nous emmener à la version 1.0 final début septembre, comme l'annonce la roadmap.

Au menu des principales nouveautés depuis la version 0.96.x :

• Nouvelle interface d'administration
• Support de l'unicode
• Amélioration de l'ORM
• L'autoescaping dans les templates, pour se prémunir des failles XSS.

Pour ceux qui mettraient à jour leur site d'une version 0.96.x vers cette version, n'oubliez pas de consulter la liste des incompatibilités ascendantes et le traitement à "infliger" à votre code pour le faire évoluer.

Sur la partie admin, je vous invite à consulter également la page dédiée à cette fonctionnalité qui donne beaucoup d'informations pour la migration. A lire et voir également, ce tutoriel et screencast pour la migration vers cette nouvelle interface d'administration.

Et pendant ce temps-là sur django-fr, David a (enfin ) publié mes traductions de la contrib webdesign, l'installation de django avec Apache/mod_python ou sous fastcgi. Il faut d'ailleurs que je mette à jour ces deux documents suite aux derniers commits...

PS : désolé pour le jeux de mot... fatigue, besoin de vacances, tout ça tout ça...