Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

L'outil de suivi de bogues de Windows 1.0 était un simple fichier texte, explique Raymond Chen, un développeur du SE,
En retraçant l'évolution du fichier et son adoption au sein de Microsoft

Le , par Olivier Famien

523PARTAGES

12  0 
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 ?

Quel jugement faites-vous de l’utilisation d’un fichier texte pour gérer un projet aussi énorme que Windows ;?

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

Microsoft envisage de créer un tableau de bord des bogues pour Windows 10 afin de faciliter la tâche aux utilisateurs
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
Microsoft : un bogue Windows « ;wormable ;» pourrait conduire à un autre WannaCry, les utilisateurs d’anciennes versions doivent appliquer le patch

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de frfancha
Membre éprouvé https://www.developpez.com
Le 20/03/2020 à 7:58
Quand le temps de suivre toutes les formalités Jira est le double de celui nécessaire à la correction elle-même du bug on regrette le temps où un suivi dans une bête feuille Excel faisait le job
8  0 
Avatar de LeBressaud
Membre averti https://www.developpez.com
Le 20/03/2020 à 11:07
Citation Envoyé par frfancha Voir le message
Quand le temps de suivre toutes les formalités Jira est le double de celui nécessaire à la correction elle-même du bug on regrette le temps où un suivi dans une bête feuille Excel faisait le job
Ça a le mérite d'occuper les managers et autres "Scrum Master", pendant qu'ils jouent à celui qui ferra le workflow le plus incompréhensible on est plus ou moins peinard
2  0 
Avatar de defZero
Membre extrêmement actif https://www.developpez.com
Le 21/03/2020 à 22:33
Quel jugement faites-vous de l’utilisation d’un fichier texte pour gérer un projet aussi énorme que Windows ;?

C'est à remettre dans le contexte de l'époque.
Windows n'était surement pas le seule et puis, si ça faisait le job, c'est l'essentiel non ?
La preuve, dès que l'approche a montré ses limites, ils en ont changés pour s'adapter.

Avez-vous déjà eu recours à un simple fichier pour gérer le suivi de bogues ou d’autres éléments de votre projet ;?

Bien-sur, comme tout le monde en débutant, je pense.
C'est quand même la méthode la plus simple pour commencer.
Et puis, sur de petits projets, c'est largement suffisant.

Ah oui Jira ... On perd un temps monstrueux malgré son efficacité. ...
@transgohan
Comment des outils qui font "perdre du temps" peuvent être qualifié d' "efficace" ?
Surtout pour un logiciel qui ce veut spécialisé.
Comprend pas .
2  0 
Avatar de transgohan
Expert éminent https://www.developpez.com
Le 20/03/2020 à 11:21
Ah oui Jira...
Cet outil qui demande de remplir x champs avant de simplement pouvoir passer à l'étape suivante...
On perd un temps monstrueux malgré son efficacité.

En plus son interface n'est pas claire, la partie réalisation qui est quand même la plus importante après la description du bug est super petite... Une joie quand on se réfère à un ticket pour comprendre le correctif...

On veut de plus en plus de logiciels qui font le café, et qui s'adapte au plus grand nombre plutôt que de faire des outils adaptés.
C'est dommage.

Moi je milite pour un juste milieu entre RAID et Jira.
0  0 
Avatar de jpouly
Membre averti https://www.developpez.com
Le 20/03/2020 à 20:13
Citation Envoyé par Olivier Famien Voir le message
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.
A bon, Windows 1.0 était un système d'exploitation . C’était plutôt une surcouche à DOS.

Citation Envoyé par Olivier Famien Voir le message

Quel jugement faites-vous de l’utilisation d’un fichier texte pour gérer un projet aussi énorme que Windows ;?
Dans les années 80/90, ça ne me choque pas. Après, des outils de suivi de bugs sont apparus (Mantis, Bugzilla, ...), principalement développé en PHP, Java ...

Après, pour dédouaner M$, j'ai des clients qui ont des applis que j'ai développer, qui tournent depuis 20 ans. Et tant que ça marche, pourquoi le changer.

Citation Envoyé par Olivier Famien Voir le message

Avez-vous déjà eu recours à un simple fichier pour gérer le suivi de bogues ou d’autres éléments de votre projet ;?
Mon dernier gros projet, on a commencé avec un fichier Excel, avant de découvrir l'outil FeedBack de TFS. On a laissé les testeurs s'en servir .

Finalement, on est revenu sur Excel, car on maîtrisait mieux les entrées dans le bordel. Et on n'était plus noyé sous les remarques/demandes/trucs bizarre/...
0  0 
Avatar de transgohan
Expert éminent https://www.developpez.com
Le 24/03/2020 à 10:25
Citation Envoyé par defZero Voir le message
Comment des outils qui font "perdre du temps" peuvent être qualifié d' "efficace" ?
Surtout pour un logiciel qui ce veut spécialisé.
Comprend pas .
En fait il fait gagner du temps sur certains aspects, comme la remontée et la centralisation des informations.
Mais pour l'avancée des états par contre c'est une calamité...
0  0