Le développement logiciel a été multiplié par 100 depuis l'invention d'Internet, mais la façon dont les gens signalent les bogues n'a pas changé depuis les années 1990. Avez-vous déjà vécu cela? Un ingénieur récupère un ticket, et après une enquête, ils déterminent que cela fonctionne bien de leur côté, et qu'ils n'ont pas suffisamment d'informations pour reproduire le bogue. Ils ajoutent un commentaire au ticket, passent à une tâche différente et attendent que le rapporteur de bogue leur fournisse plus d'informations. Ce cycle se répète plusieurs fois, et chaque fois qu'il y a de nouvelles informations dans le ticket, l'ingénieur doit se rappeler où ils se sont arrêtés et essayer de reprendre le fil. Les changements de contexte comme celui-ci sont pénibles pour les ingénieurs, et le processus typique de signalement de bogues semble être l'enfant de l'affiche pour ce genre de tracas. La vraie vie d'un bug Imaginez qu'un collègue signale un problème de connexion dans le canal d'ingénierie Slack et que deux ingénieurs abandonnent tout pour enquêter. Malgré tous leurs efforts, ils ne peuvent pas reproduire le problème. Ils demandent plus d'informations telles que le type de navigateur et d'appareil. Ensuite, ils demandent à l'employé d'essayer diverses étapes de dépannage, comme vider le cache et actualiser la page. Les discussions asynchrones dans les deux sens consomment souvent une heure ou plus. Finalement, l'équipe d'ingénierie doit planifier un appel de débogage avec l'employé pour essayer d'identifier le problème sur son ordinateur. Pendant l'appel, l'employé partage son écran et les ingénieurs le guident sur la façon d'ouvrir les onglets console et réseau dans les outils de développement pour discerner ce qui se passe. Finalement, les ingénieurs voient qu'il y a une erreur 401 dans l'onglet réseau, qui dit "mot de passe incorrect". Essentiellement, le problème n'était pas que la connexion était interrompue, c'était que le frontal n'a pas réussi à afficher le message d'erreur "mot de passe incorrect" et à l'afficher à l'utilisateur. Une simple erreur frontale qui aurait dû prendre cinq minutes pour être identifiée et résolue a coûté l'après-midi à quelques ingénieurs. Temps pour le changement Le processus de rapport de bogue d'aujourd'hui reste archaïque. Depuis les années 1990, le monde a inventé la messagerie instantanée comme Slack et les appels vidéo comme Zoom, et a adopté le travail à distance à l'échelle mondiale. La communication sur les bogues est devenue numérique. Le suivi des bogues est passé des fichiers écrits aux tickets Jira. Et pourtant, les rapports de bogues sont toujours remplis de va-et-vient embêtants qui font perdre du temps à l'ingénierie. Nous avons tous connu la frustration de traiter des rapports de bogues peu clairs qui manquent du contexte nécessaire pour résoudre le problème. C'est pourquoi il y a un an, quelques-uns d'entre nous ont commencé à imaginer une meilleure façon. Et si nous pouvions créer un nouvel outil qui modernise les rapports de bogues et pourrait résoudre le problème des rapports de bogues peu clairs, réduire le besoin de communication aller-retour et faire gagner du temps et de l'énergie aux ingénieurs ? Et donc, l'idée de est né. Un outil conçu pour rendre le processus de signalement de bugs plus productif et efficace. Nous voulions créer une solution qui aiderait les ingénieurs à résoudre les bogues techniques, et non les problèmes de communication. Confiture Nous avons donc décidé de créer un outil qui permettrait à quiconque, quelle que soit sa formation technique, de capturer des données techniques contextuelles riches sur les bogues, afin que les ingénieurs puissent rapidement identifier et résoudre les problèmes. Nous voulions créer un outil qui faciliterait la vie des ingénieurs, tout en aidant les personnes qui leur signalent des problèmes à être également plus efficaces. Lorsque nous avons développé et testé Jam au début de l'année dernière, nous avons vu le potentiel qu'il avait pour accélérer le fonctionnement de notre propre équipe. Par exemple, prenez ce Jam of a bug dans notre propre code. Au lieu de devoir sauter sur un appel pour déboguer en direct, nos ingénieurs ont pu voir quel était le problème, directement à partir du rapport de bogue lui-même. Nous avons commencé à partager Jam avec d'autres équipes d'ingénieurs, et nous avons été vraiment enthousiasmés par la réponse. Ramp, T-Mobile et Dell ont été parmi les premiers à adopter Jam et ont fourni des commentaires inestimables qui nous ont aidés à façonner le produit. En itérant sur leur contribution, nous sommes maintenant fiers de dire que Jam compte plus de 14 000 utilisateurs et compte. Mais notre travail est loin d'être terminé. Nous savons que le processus de signalement de bogues peut être une source majeure de frustration pour les ingénieurs, et nous nous engageons à changer cela. Si vous en avez marre des rapports de bugs peu clairs, nous vous invitons à essayer Jam et à nous dire ce que vous en pensez. Nous avons pour mission de bâtir un avenir meilleur pour l'ingénierie et nous avons besoin de vos commentaires pour y arriver. Vous pouvez me contacter personnellement à dani@jam.dev et nous rejoindre dans ce voyage.

Cet audio est produit dans la langue originale de l'histoire !

Trop long; Pour lire

Making security fun one episode at a time

Les années 1990 appelées, ils veulent que leur processus de signalement de bogues revienne

Trop long; Pour lire

Dani Grant

About Author

ÉTIQUETTES

Languages

CET ARTICLE A ÉTÉ PARU DANS...

Les années 1990 appelées, ils veulent que leur processus de signalement de bogues revienne

Trop long; Pour lire

Dani Grant

About Author

ÉTIQUETTES

Languages

CET ARTICLE A ÉTÉ PARU DANS...

HISTOIRES CONNEXES