Depuis mon arrivée sur le player, j'ai eu à corriger entre autre un problème récurrent que je qualifie comme le "bug de défilement des zones séquences dans une diapositive". L'ensemble des tickets (que j'ai retrouvé) qui sont liés à ce bug (ou ce type de bug) sont les suivants :

http://redmine/issues/14679
http://redmine/issues/14651
http://redmine/issues/14571
http://redmine/issues/14479
http://redmine/issues/14507
http://redmine/issues/14980
http://redmine/issues/15373
http://redmine/issues/4924
http://redmine/issues/14147
http://redmine/issues/13848

La correction de ce bug implique des parties sensibles du code du player, parties de code difficiles aujourd'hui à tester en intégralité par des tests manuels (Media4Display est un produit complet dont les possibilités d'usage sont très larges, et il est tout à fait déraisonnable de penser qu'un seul développeur puisse réaliser des tests manuels ayant une couverture suffisante du produit pour en découvrir les bugs possibles, ce même sur une fonctionnalité précise avec une bonne connaissance du code). Aussi, chaque correction amène une certaine probabilité d'engendrer un nouveau bug, ce qui se vérifie puisque la dernière correction que j'ai effectué en rapport à ce bug (#15373) a engendré un nouveau bug plus grave révélé lors de la 2eme campagne de test de M4D 5.0.1 (crash du player lors de la diffusion d'une page web avec le moteur chrome). J'ai pourtant effectué cette correction avec le concours de Quentin et de Guillaume.

Mon opinion aujourd'hui est que la partie du player qui gère la diffusion des médias (timing en particulier) est difficilement maintenable, et que son vieillissement (avec l'apparition des zones séquences et des effets d'apparition et de disparition en particulier) l'a rendu imprécis (du point de vu de la diffusion) et désordonné (du point de vue du code). Toute correction effectuée ne peut être garantie sans effet de bord non anticipé, effets potentiellement importants. Il s'agit donc de passer toujours beaucoup de temps à tester manuellement le player dans le cas d'une modification dans cette partie, ce qui est fastidieux, et loin de garantir quoi que ce soit.

Le fait de n'apporter toujours que des "micro-corrections" ne permettra jamais d'assainir cette situation qui à terme pourrait devenir un frein quant au potentiel de précision et d'exactitude du player. Pourtant, cela ne me semble pas être insurmontable d'améliorer cette partie du code pourvu qu'on y accorde du temps. Cela implique les tâches suivantes :
1) Etudier et réaliser une solution afin d'automatiser des tests de diffusion garantissant que chaque version livrée du player réponde au moins à des exigences simples mais de base (typiquement, éviter les crashs lors de la diffusion d'un média ou d'une diapositive simple, s'assurer que le défilement des séquences soit correct...). Cette étape est primordiale puisque armés d'outils de tests automatiques, on pourrait au fur-et-à-mesure de la vie du player éliminer de plus en plus de cas de bugs par la rédaction de nouveaux tests. Ce faisant, nous pourrions nous concentrer davantage sur la couverture fonctionnelle du player plutôt que sur sa stabilité ou son exactitude ; cela implique de plus à terme des campagnes de test plus courtes et moins fastidieuses avec une confiance accrue dans la qualité de notre produit ;
2) Etudier les principaux problèmes architecturaux et de conception du player, et apporter au code les modifications nécessaires afin de garantir une maintenance plus aisée et ouvrir le champs des possibles aux aspects fonctionnels ;

De manière générale, je pense que ce qui est dit dans ce ticket n'est pas vrai que pour l'ordonnancement de la diffusion des médias dans le player, mais aussi pour d'autres aspects (interface d'édition des sources de données, éditeur de diapositive [aspects tests pour ce dernier], etc). Je pense également que la plupart (sinon tous) des développeurs ici sont en mesure d'avoir le recul nécessaire pour dire en quoi le code sur lequel ils travaillent nécessiterait d'être retravaillé, et en quoi automatiser son test serait un gain de temps et un gage de qualité considérable à terme. Il me semble que ce sentiment est largement partagé par la plupart de mes collègues.

C'est au vu de ces éléments que j'aimerais aborder ces questions lors d'une réunion afin de pouvoir en discuter plus en détail, et voir si un plan d'action serait envisageable dans ce sens.