1 pièce(s) jointe(s)
L'outil de suivi de bogues de Windows 1.0 était un simple fichier texte, explique Raymond Chen
L'outil de suivi de bogues de Windows 1.0 était un simple fichier texte, explique Raymond Chen, un développeur de longue date du SE,
en retraçant l’évolution du fichier au fil des années et comment il a été adopté dans tout Microsoft
Lorsque vous développez un logiciel, l’évidence voudrait que vous disposiez d’un système d’enregistrement des bogues. Pour Microsoft, cette exigence fut également de mise lorsque l’entreprise est passée de MS-DOS à Windows 1.0. Mais en 1985, alors que Windows se dotait de sa première couche graphique, avoir un logiciel de gestion de versions était impossible. Pour suivre donc les bogues dans ce système d’exploitation (abrégé SE), l’équipe de Windows 1.0 a simplement utilisé un fichier texte.
Pour comprendre comment ce fichier a vu le jour et a évolué dans le temps avec Windows et les autres produits, Raymond Chen, un développeur de longue date de Windows explique qu’après la sortie de Windows 1.01, un groupe de personnes de la division des applications s’est réuni et a créé une base de données de suivi des bogues avec un fichier texte. Comme nom, l’équipe a retenu RAID qui est le nom d’une marque d’insecticides aux États-Unis qui utilise le slogan « Kills bugs dead » (entendez par-là, il tue les insectes morts). L’icône du programme était naturellement une bombe anti-insectes. Pour rester dans l’esprit des corrections de bogues, l’équipe a déclaré que RAID était l’acronyme de « Reporting And Incidents Database », mais personne ne le savait ou ne s’en souciait. C’était du RAID. Et l’extension du fichier était .rdq, l’abréviation de « RAID Query ».
Lorsque vous aviez découvert un bogue, il suffisait de créer une requête et de l’enregistrer pour une utilisation ultérieure. Selon Chen, le nom RAID fut linguistiquement productif, car vous pouviez effectuer un RAID sur un bogue, ce qui signifie « Déposer un bogue dans la base de données RAID du projet ». L’extension .rdq pouvait également être utilisé comme nom propre, en faisant référence au fichier de requêtes.
Étant donné que la base de données avait été écrite à l’époque où l’informatique était encore au 16 bits, elle comportait donc une limite d’enregistrement de 32 767 bogues. Pendant des années, ce fichier a été utilisé sans problèmes. Mais avec les nouvelles versions de Windows et l’accroissement des bogues découverts, ce fichier a atteint ses limites. L’équipe de Windows a dû naturellement basculer vers une nouvelle base de données où tous les bogues de l’ancien fichier qui n’avaient pas encore été fermés ont été copiés dans la nouvelle base de données (et ont reçu un nouvel enregistrement et l’ancienne base de données a été mise en lecture seule). Jusqu’à Windows XP, l’équipe de développement a édité plusieurs versions de la base de données RAID.
Mais lorsque l’équipe de Windows travaillait sur le développement de Windows XP, il arrivait que les utilisateurs de RAID se retrouvaient dans des situations où il y avait tellement de personnes qui l’utilisaient en même temps que le serveur cessait d’accepter de nouvelles connexions. Dans certains cas, lorsque l’équipe de publication de Windows se réunissait pour examiner l’état du système en cours de développement, elle devait appeler les opérations et leur demander de supprimer quelques connexions actives à la base de données principale afin que leurs membres puissent se connecter. Il était clair que RAID avait été poussé bien au-delà de sa conception initiale, confesse Chen.
Pour régler ces problèmes d’évolutivité rencontrés avec les premières versions de RAID, un nouveau système de suivi des bogues nommé Product Studio a été développé. Il a été nommé ainsi, car le nom des applications à la mode à l’époque était « Quelque chose Studio ». Product Studio qui avait une architecture à trois niveaux ne présentait pas les limites de nombre d’enregistrements de RAID, mais comportait des bogues, comme celui du niveau intermédiaire. Jusqu’à Windows 8, l’équipe de développement du système d’exploitation a continué d’utiliser Product Studio puis est passée à Team Foundation Services sur site. Mais comme pour les bases de données antérieures, Product Studio a également montré des insuffisances ce qui a poussé l’équipe de Windows à se tourner vers Visual Studio Online pour le suivi des bogues après la sortie de Windows 10. Des problèmes de stabilité étant survenus, l’équipe de Windows a à nouveau migré, cette fois-ci, vers Visual Studio Team Services, puis sur Azure DevOps Services. Malgré la migration sur l’outil de collaboration cloud Azure DevOps, Chen rapporte que cette plateforme n’était pas assez grande pour contenir tous les rapports de bogues. Périodiquement, les anciens éléments de travail sont archivés et déplacés vers un autre projet.
Selon Chen, « les auteurs originaux de RAID n’avaient aucune idée que leur petit outil de base de données de suivi des bogues serait le principal outil de suivi des défauts dans tout Microsoft pendant plusieurs décennies. S’ils l’avaient su, ils auraient peut-être eu trop peur de l’écrire ». Il ajoute qu’en « repensant à l’origine du RAID, l’un des développeurs d’origine a avoué que ce fichier “n’était vraiment pas fait pour durer aussi longtemps” ». Mais la réalité a montré le contraire. Un petit fichier texte conçu à l’origine pour gérer 32 767 bogues a migré et est devenu un outil de gestion de bogues de tout Microsoft.
Source : Microsoft
Et vous ?
:fleche: Quel jugement faites-vous de l’utilisation d’un fichier texte pour gérer un projet aussi énorme que Windows ?
:fleche: Avez-vous déjà eu recours à un simple fichier pour gérer le suivi de bogues ou d’autres éléments de votre projet ?
Voir aussi
:fleche: Microsoft envisage de créer un tableau de bord des bogues pour Windows 10 afin de faciliter la tâche aux utilisateurs
:fleche: Windows 7 : pas de correctif officiel, mais des astuces pour contourner un bogue qui empêche les utilisateurs d’éteindre ou redémarrer leur système après la fin du support de l’OS
:fleche: Microsoft : un bogue Windows « wormable » pourrait conduire à un autre WannaCry, les utilisateurs d’anciennes versions doivent appliquer le patch
