Depuis maintenant les quelques années que je travaille dans le développement pour le web, une fonctionnalité a changé ma vie de développeur: les outils de versionning et SubVersion en particulier (je parlerais de mes malheureuses aventures avec CVS peut être dans un autre post)

1. C’est quoi un outil de versionning
Un outil de versionning c’est un outil qui va vous permettre de stocker différentes version de vos fichiers. Il existe plusieurs types d’outils de versionning (si je me trompes pas Microsoft à lui aussi un outil de versionning), mais les plus connus sont CVS et son petit cousin SubVersion.

2. Pourquoi le mettre en place?
Si vous êtes plusieurs à travailler sur un projet en particulier si certains fichiers sont en commun, si vous désirez garder une trace des différentes versions de vos fichiers… les outils de versionning sont faits pour vous.
Pour résumer si vous travaillez dans le développement, vous avez 98% de chance d’avoir besoin de cet outil (même pour les graphistes cela peut se révéler très utile).

3. Les contraintes
Elles sont pu nombreuses:
- de la discipline (s’astreindre à suivre la procédure en place, ne pas buypasser le système même si cela paraît plus simple, au final tout le monde y perds)
- updater et commiter souvent (ce sont les deux actions principales pour mettre à jour et envoyer une nouvelle version du fichier)
- commenter ses commit (si vous avez 275 versions d’un fichier en une semaine, même si les révisions sont notées par heure d’envoi, sans commentaires efficaces vous allez vous y perdre très vite)

4. Architecture typique

Imaginons par exemple que vous ayez deux développeurs: machin et bidule, une plateforme de test et une plateforme de production.
L’architecture typique est d’avoir 4 environnements distincts tous synchronisés avec votre Repository (l’endroit où subversion stocke les fichiers et leurs modifications)

5. Les défauts?
Ils ne sont pas nombreux:
- expliquer et éduquer comment bien utiliser subversion (et avec certains ça peut prendre du temps)
- devoir résoudre certains conflits “à la main”

Et vous est ce que vous utilisez des outils de versionning?

Petite séance de debuggage CSS avec Dame Tartine, qui pour l’occasion essaye de caser le plus grand nombre d’ordinateurs sur une même table.
Le debuggage c’est toujours un peu la galère, même en essayant de faire le code le plus propre possible et le plus cross-plateforme possible, il y a toujours du travail.
Que ce soit pour le CSS ou le javascript… plusieurs OS, plusieurs Browsers: pleins de possibilité de plantages et de merdouilles. Même si il est possible d’émuler plus ou moins certains navigateurs sur certaines machines, le meilleur moyen reste encore d’avoir physiquement ces différents environnements à disposition.

Le debuggage est aussi une galère pour les chefs de projets… puisque difficilement quantifiable, on peut estimer “à la louche” quel temps devrait prendre tel ou tel correction de bug, mais aucune estimation fiable.

Et vous c’est quoi votre méthode de debuggage?

Aujourd’hui deux applications extrêmement utiles pour tous les Travailleurs Du Web qui sont sur Mac (désolé pour les Windowsiens/Linuxiens si quelqu’un veut écrire des articles Win/Linux il est le bienvenu…)

MacFusion
Je vous avais déjà parlé il y a de cela quelques temps de MacFuse et SSHFS qui permettait de monter un accès SSH à votre serveur sur un lecteur réseau… seul problème à chaque ouverture, il fallait retaper le mot de passe, l’adresse ip, etc… aujourd’hui le problème est réglé puisqu’avec MacFusion, vous montez vos lecteurs réseau en un clic.
C’est ULTRA pratique, une des deux raisons pour moi (avec TextMate) pour lesquels tous les dev OpenSource devraient switcher sur Mac (oui je sais je suis un peu extrémiste, mais j’assume totalement).
Vous pouvez trouver MacFusion ici (et je pense que vous devez installer MacFuse avant, à confirmer)

DesktopCurtain
Un petit utilitaire bien pratique si comme moi vous avez un bureau plutôt bordélique (je fais le ménage régulièrement mais 95% du temps ça reste un peu le fouilli), mais que de temps en temps vous avez besoin de faire des captures d’écran ou des screencast sur un bureau vierge et propre…
DesktopCurtain est là pour vous, puisqu’il affiche un bureau clean au dessus de voter Desktop, sans toucher à vos fichiers stockés un peu n’importe où sur votre bureau…
C’est disponible ici et c’est gratuit!

Lors de la conduite d’un projet, les pièges sont nombreux surtout niveau technique, voici donc une petite liste des écueils connus à éviter à tout prix.

1. Conception fermée
C’est souvent une des difficultés majeurs pour le suivi d’un projet technique. Le projet en cours de route évolu, change, se métamorphose… certains fonctionnalités disparaissent, d’autres apparaissent, des contraintes nouvelles viennent s’ajouter au projet. Tous ces changements doivent pouvoir être pris en compte au fur et à mesure et ne pas être un frein pour le bon déroulement technique du projet. La conception aussi bien de la plateforme de production, que de la base de donnée ou de l’applicatif doit être flexible et ouverte… donnant du champ à des modifications.

2. Outils performants
C’est un des pièges récurrents, principalement dans les grandes structures, trouver des outils performants qui ne freinent pas le développement. Cela peut consister en des machines vieillottes ou qui tombent en panne, des problèmes réseau, des serveurs de l’ère du crétacé… ou simplement des procédures de mise en ligne trop longues qui vous bouffent votre temps de développement.

3. Versionning / sauvegarde
Un de vos soucis (si vous suivez un projet) est de s’assurer de deux choses:
- que des sauvegardes régulières sont faites aussi bien des données que du code source, à des intervalles réguliers, en essayant de varier les supports et en archivant régulièrement (je me souviens plus où j’avais lu ça, mais une étude avait montré qu’environ 20% des boites high-tech fermaient les portes après un accident de matériel faute de vraie politique de sauvegarde).
- que les développeurs ne se marchent pas sur les pieds, et donc utiliser un outil de versionning… éviter les cas classiques, qui sont: pierre enregistre un vieux fichier qu’il avait en local et bousille une semaine de boulot de paul, ou encore pouvoir revenir à une version précédente du code, très très pratique.

4. L’euphorie post-démo
Souvent pour sortir une démo à temps, on est tenté (et certaines fois on a pas trop le choix) de couper dans certaines principes qu’on c’est fixé… on fait des dev un peu plus cradocs, on néglige certaines parties, etc… rien de dramatique en soit, si on redresse au plus vite la situation. Le risque majeur est qu’on ait pas le temps de redresser les petites cochonneries qu’on a pu faire pour que la démo marche et que l’on continue dans cette voix. Pansement sur jambe de bois, sur bout de scotch, sur bout de ficelle et on va à moyen terme dans le mur.

5. Garder le cap
C’est une des tâches les plus dures et c’est un des rôles essentiels du Chef de projet technique: emmener tout le monde dans la même direction, avec le moins d’accrocs possibles, avoir une double vision: macroscopique du projet, mais aussi aller dans les détails du code ou de la conception de données pour que le projet fonctionnellement et techniquement ailles dans la bonne direction.

Il doit certainement ex exister d’autre mais ce sont les 5 principaux écueils à éviter quand on gère un projet technique. Et vous des expériences ou remarques à partager?

[oui c’est bien l’un de nous qui comate pied nu à 6h du matin par terre!]

Voilà après près de 21h de code, debuggage, montage, adaptation presque ininterrompu (on a quand même pris le temps de manger de temps en temps, sans compter les X clopes que je me suis envoyé durant la nuit, je sais c’est pas bien) me revoici de retour à mon poste après quelques heures de sommeil.
La démo était prête le jour dit, donc aujourd’hui à 7h du matin environ… hourra!
Un peu la tête dans le sac (j’ai faillit choisir une autre expression, mais non… restons léger et courtois) mais content d’avoir pu délivrer le résultat attendu (ou presque à quelques iotas près) plus ou moins dans les temps.

[6h30 on est super fresh!]

Mais le propos du jour n’est pas vraiment la nuit passé sur la démo (enfin partiellement en tout cas), mais plutôt sur les derniers jours d’un projet qui sont toujours importantes, stressantes et décicives.

1. Jamais dans les temps
Dans toute ma (longue?) carrière, je n’ai JAMAIS (et là un doute m’assaille, est ce que je suis nul? nan…) rendu un projet dans les temps, jamais. Toujours des fonctionnalités qui viennent s’ajouter, des zones d’ombres pas levées avant le développement du module, des difficultés techniques imprévues, etc… Donc si vous voyez que votre projet du retard, c’est (plus ou moins) normal, pas la peine de stresser outre mesure.

2. Eviter le stress non productif
C’est sans doute une des clefs pour boucler un projet… c’est l’ultime conseil que je pourrais donner, ne vous auto-stressez pas avec des angoisses de dernière minute non productive, du type le serveur qui plante et qui veut pas re-démarrer. Calmez vous (et les gens autour de vous), allez faire un tour, buvez un coup, fumez une clope (ou mâchez un cheawing-gum)… revenez serein (même si c’est pas complètement le cas) et résolvez le probème calmement. Souvent du stress vient plus d’erreurs que vous devrez corriger par la suite. Prenez les problèmes dans l’ordre de façon méthodique, même si tout le monde stresse et s’énerve, cri ou pleure… restez serein et concentré sur votre task-list.
Surtout lors du débuggage final, vous trouvez de temps en temps des effets de bord (qui pour une bonne partie se corrigent d’eux même après avoir fixé les principaux bugs déjà listés), ne vous jetez pas dessus, notez les et suivez calmement votre tasklist, sinon vous risquez de vous disperser et de passer encore plus de temps dessus.

3. Se concentrer sur l’essentiel
Vous ne pourrez pas livrer toutes les fonctionnalités à la date prévue? pas un drame… concentrez vous au maximum sur le coeur de votre projet, les fonctionnalités à très forte valeur ajoutée. Si le reste passe à l’ouest, pas grave, vous aurez peut être un peu de temps pour vous y atteler, quand l’essentiel sera réglé.

4. Redimensionner le résultat au besoin
N’hésitez pas à zapper certaines fonctionnalités pour les inclures dans une livraison suivante. Mieux vaut un projet réduit mais bien fini, qu’un produit bordélique, plein de bugs et baclé.

5. Les merdasses de dernière minute
Gardez vous un peu de temps pour parer aux éventuelles merdasses qui ne manquent pas d’arriver, surtout si vous partez pour un environnement hostile (une démo chez un client). Prévoyez un ordinateur de secours si le votre tombe en rade, une sauvegarde sur DVD ou bien un accès via le web… ou suivant les cas, quelques heures pour assurer une mise en ligne correcte (on sais jamais ce qui peut arriver aussi bien à l’export qu’à l’import). C’est souvent les dernières heures qui sont les plus cruciales, qui font que votre travail de quelques semaines/mois seront évalués à leur juste valeur (ou pas).
Prévoyez donc une marge confortable pour tout ce qui peut arriver dans les dernières heures et ne mettez pas en ligne à la dernière minute, prévoyez une mise en ligne intermédiaire quelques heures avant (ce qui vous permettra de voir éventuellement si la mise en ligne est rapide ou si elle nécessitera plus de travail).

[le dernier transfert de la base de donnée en local sur le laptop de mon boss, qu’on a du refaire trois fois!… à 6h43 la dernière ligne droite (on voit d’ailleurs les pieds du comateux en bas de la photo à gauche…)]

Et vous, des anecdotes/histoires de finalisation/mise en ligne de projet?