Capripot, le blog !

Le dernier show qui m’avait vraiment impressionné niveau technologies déployées c’était le 360° Tour de U2. Là, Live Nation a fait encore mieux pour son premier album signé avec la Madonne. Regardez plutôt ce par-terre d’écrans géants ! C’était le show de la finale du Super Bowl de cette année. Amazing non ?!

Trop trop marrant, je suis tombé sur cette vidéo à la télé dans laquelle Cheryl Cole chante « Alouette, déployer les ailes, Alouette plumerai les ailes ».

Ce qui est le plus drôle c’est qu’elle dit « Alouette uette uette deployer les allés », pas très compréhensible en français quand même ^^ Autant dire que j’étais plié devant ma télé

Pendant ces 6 mois j’ai aussi constater que la plus part du temps, pour des développements assez longs pour des fonctionnalités un peu plus compliquée qu’un simple new/edit/delete, je pouvais être assez lent.

Plusieurs jours parfois même. Le soucis ne situe pas dans la complexité du problème, mais dans le fait qu’on est sans interrompu. Un café par ci, un encas par là, un collègue qui vous pose une question ou qui fait une blague, le déjeuner, le coup de barre inévitable qui en découle. Tout ceci fait qu’à chaque fois, je me déconcentrait, je perdais le fil de ma pensée…

Je n’avais pas souvent été confronté à ce problème auparavant puisque l’ensemble des développements importants que j’avais réalisés s’étaient fait soit chez moi, sans aucun contrainte de temps/événement, soit la nuit.
La nuit est le meilleur temps pour développer. Et effectivement, par rapport à un travail effectué la nuit, le temps global développement était clairement allongé.

Tout ça pour dire que je pense préférer largement développer la nuit que le jour !

Ca fait prêt de 6 mois que je suis réellement développeur dans une entreprise à plein temps. Cela me plait bien, surtout la partie compréhension du problème et recherche de la meilleur solution possible en terme de structure data ou d’interface utlisateur.
Les plus gros problèmes que j’ai rencontrés n’étaient pas des casse-têtes de conception ou des choses irréalisables, non. Le problème principal est de comprendre le besoin du client. Vous allez me dire « il suffit de lui demander ». Oui, mais le client ne sais généralement pas ce qu’il veut. Et c’est à cet instant que tout ce complique.

Le métier de concepteur consiste en grande partie à poser les bonnes questions, et de (très) nombreuses questions. Le client ne connais que ce qu’il manipule. Il faut donc passer par des métaphores et comprendre toutes les dépendances entre les différents éléments qu’il vous demande de mémoriser dans son futur système d’information.
Le but est de ne jamais oublier de question et d’en poser suffisamment. Si un jour vous êtes un peu fatigué, un peu moins en forme et que vous oubliez de poser une question, il se peut qu’un mois ou deux après la conception de votre schéma de base de donnée, il y ait une énorme erreur de dépendance. Et cette dépendance contraint bien évidemment le fonctionnement de vos vues et de vos controllers.

Le pire qui peut arriver c’est que le client, malgré vos questions à répétition ne pense pas bien à son propre usage, et vous réponde « oui oui c’est très bien ». La plupart du temps, c’est uniquement le jour ou il en a besoin et où il l’essaye réellement qu’il se rend compte que ça va pas.

Typiquement « Ah mais je ne vous avais pas dit, il peut y avoir plusieurs options de routage (plusieurs lignes de fabrication) pour la confection de cette pièce ».
Votre système était bien évidemment conçu pour attribuer une seule option de routage (un  menu déroulant) alors que maintenant, le client veut pouvoir faire une sélection multiple. Ca change toute votre vue et la relation 1-1 se transformant en 1-n, ça change également votre contrôleur et même votre modèle.
Et hop, on recommence tout.