sache qu’il y a une conférence sur Python, entièrement gratuite, qui se tiendra le 30 et 31 mai (autant dire, le week-end prochain) sur Paris, à la Cité des Sciences et de l’Industrie de la Villette.

Tarek Ziadé, le président de l’association AFPY, donne un peu plus de précisions sur cet évènement.

Et enfin un lien vers l’évènement lui même, afin d’y trouver des informations sur le programme: PyCon.fr 2009

J’y donnerai une présentation de 20 minutes sur un billet que j’ai commencé sur ce blog: Les (D)VCS, pourquoi, comment? (le premier article: Le contrôle de version de sources, pourquoi?)

Le crash disque

Brian n’a pas de chance, et il a failli devoir pointer à l’ANPE quand il s’est rendu compte que

1. Son disque dur avait crashé
2. Il n’avait pas fait de sauvegarde de son boulot

Heureusement, il a pu récuperer les sources sur le serveur de production, et en moins de deux semaines il a pu réimplémenter les dernières fonctionnalités et corrections de bugs qu’il avait apportées au logiciel.

Le boss indécis

Brian n’a vraiment pas de chance, il a un boss indécis qui vient de lui dire qu’il ne voulait finalement plus de la dernière fonctionnalité en date:

« c’est une très mauvaise idée, commercialement parlant, supprime là au plus vite ».

Trois jours plus tard, Brian pense n’avoir oublié d’annuler les modifications dans aucun fichier.

La faute à Murphy

Brian, qui a la poisse, se retrouve à débuguer un morceau de code obscur, et se demande tout à coup qui a bien pu créer ce « code spaghetti ».

• Serait-ce John, le cousin de l’oncle de sa soeur, qui code comme sa grand-mère?
• Ou encore Steven, le surfer blond, qui sort juste de l’école et n’a jamais appris à commenter son code?

Si seulement Brian le savait, il pourrait demander des éclaircissement à l’auteur, et aurait quelqu’un à pointer du doigt à son boss qui vient de sortir son fouet.

Le CPOLD: la fausse solution

Pour reprendre le blog de Roland, le CPOLD à d’innombrables qualités:

• pas de format de fichier complexe et susceptible de corruption
• pas de conflits
• aucun besoin d’un serveur dédié (on peut tout mettre ensemble, prod et dev confondues)
• aucune limitation sur la gestion des branches
• une rapidité insurpassable
• une simplicité de mise en oeuvre et d’apprentissage enfantine
• pas de modèle de développement imposé (centralisé, distribué, en quinconce, en hélice, toutes les variantes sont possibles)
• des sauvegardes facilitées
• etc…

Voici en quoi consiste la mise en place du CPOLD:

    $ cp fichier.py fichier.py.old

Et voici un exemple de mise en oeuvre du CPOLD:

    foo_dev
        foo.py
        foo.py.old
        foo.py.old.2009_03_29
        foo.py.marche_pas
        foo.py.todelete
        foo.py.OLD.2006_05_12
        foo.py.bak
        foo.py.fonctionalite_bar
        foo.py.bug
        foo.py.save.20081210
        foo.py.check
        foo.py.test

    foo_prod
        foo.py

    foo_savedev.tgz
    foo_save20090329_v2_0.tgz
    foo_save20080412_v1_2.tgz
    foo_save20060509_v1_0.tgz

Et pour faire bien, voici un extrait du fichier foo.py:

    ...
    def bar(thing): # Added the 10th of june, 2006 -- Steven
        """This function is very usefull!"""
        # Brian: refactored 20080410 for release 1.2
        #if thing == "bar": ### Steven: 11/06/06 fixed typo (was thing = "bar")
        #    return True;
        return (thing == "bar")
    ...

La fausse bonne idée

Nous avons déjà vu les avantages du CPOLD, maintenant les inconvénients:

• Duplication de fichiers
• Duplication de code
• Réduction dramatique de la lisibilité
• Difficulté de grouper des modifications (pour une fonctionnalité par exemple)
• Ai-je déjà mentionné la duplication?

Conclusion

Sommes-nous maintenant tous bien d’accord avec Brian pour dire que le contrôle de versions, c’est indispensable? Et que le CPOLD, c’est dépassé?

Dans une prochaine histoire, les enfants, nous verrons avec Brian quels sont les merveilleux outils à notre disposition: les « Version Control System » !