eyrolles_bilan.tex

\subsection{Bilan}
\label{section:eyrolles_bilan}

Travailler sur un projet aussi conséquent que celui de l'\aintranet\ d'\aey\ a été pour moi très instructif. En effet, il m'a permis de me confronter à de nombreuses problématiques du développement web.

Je me suis rendu compte que travailler à plusieurs développeurs sur un chantier d'une telle envergure n'était pas aussi facile que ce que j'imaginais. Déjà bien habitué au partage de code source via les systèmes de gestion de versions comme \asvn, je considérais que ces outils étaient la réponse à tous les problèmes de travail en équipe. Au-delà des simples conflits de fichiers modifiés par plusieurs parties au même instant, j'ai pu faire l'expérience de problèmes liés à la communication au sein de l'équipe de développement. Par exemple, il nous est arrivé de faire le lien entre deux tables de la base de données de trois façons différentes : chaque développeur avait implémenté la fonctionnalité à sa façon. Une solution est de ne jamais hésiter à faire le point avec ses collègues, et de régulièrement se lister l'ensemble des points que chacun a traité.

Par ailleurs, avec le recul, nous nous sommes rendus compte que l'utilisation de \asladmin\ en tant que base de chacun de nos modules n'était pas une si bonne idée. Pendant toute la première partie de la phase de développement, ce \aplugin\ nous a effectivement fait gagner du temps. Nous avons commencé à ressentir ses faiblesses quand il s'agissait de gérer des modules plus complexes : le développement devenait plus compliqué que ce qu'il l'aurait été sans utiliser \asladmin. En fait, le gros point négatif nous est apparu quand de nouveaux développeurs sont arrivés dans un deuxième temps sur le projet : ils se sont sentis relativement perdus et ont mis du temps à s'approprier le projet. Au final, on perd l'avantage d'avoir une excellente expérience commune du pôle développement sur \asf, car il faut réapprendre un nouvel outil de plus haut niveau qui est de loin perfectible et ajoute une complexité conséquente. Nous aurions dû utiliser \asladmin\ avec parcimonie et pragmatisme, c'est-à-dire uniquement sur les modules les plus simples. La décision prise par \asl\ est donc d'abandonner le développement de ce \aplugin\ et de ne plus l'utiliser sur aucun futur projet.

En outre, j'ai pu réaliser l'importance de l'écriture de jeux de tests. Cela a le double avantage d'aider à développer de nouvelles fonctionnalités, en les testant de suite, et de favoriser une maintenance plus aisée du projet en prévenant les régressions et les effets de bord. Bien que sur le court terme cette démarche prenne du temps et paraisse ennuyeuse, l'effort n'est pas vain et on est largement gagnant sur le long terme. L'utilisation d'un outil d'intégration continue tel que \asismo\ est réellement stratégique dans le sens où la démarche de test devient un véritable processus automatisé, au lieu de ne rester qu'un ensemble d'initiatives ponctuelles de la part de l'équipe de développement. La qualité est effectivement un point essentiel qui assure à l'entreprise sa crédibilité vis-à-vis au client.

Enfin, quand je suis devenu le seul développeur du projet, je me suis senti très responsabilisé. En effet, il fallait que le rythme d'avancement annoncé au client par le chef de projet soit au mieux respecté. J'ai alors eu un bel aperçu de ce que peuvent être les contraintes de temps et de résultat dans le cadre d'un projet informatique. Aussi, en effectuant la maintenance de l'application lors de la phase de recette, j'ai eu l'occasion de me confronter à du code que je n'avais pas moi-même écrit. Ajouté au fait de devoir parfois consulter le code du \afm\ \asf, j'ai pu gagner de l'expérience en terme de compréhension de code.