Si Apple a placé – avec succès – iOS 12 et macOS Mojave sous le signe de la stabilisation, préférant nettoyer le code et optimiser ces systèmes plutôt que leur ajouter des masses de nouveautés, le système mis en place par l’éditeur pour signaler les bugs, et les faire corriger, souffre de nombreux défauts, qui sont régulièrement pointés du doigt par les développeurs. Mais rarement l’un d’eux a pris le temps de détailler les problèmes qui affectent ce système, ce que fait Corin Dunn, un ancien ingénieur logiciel Apple. Et à l’en croire, ce n’est pas brillant.

Dans le maquis des composants système

« Tous les bugs sont suivis avec une application interne appelée Radar », explique-t-il. « Les employés d’Apple se connectent simplement à cette application pour signaler les bugs découverts. Les personnes de l’extérieur utilisent le site Web « Bug Reporter« , qui n’affiche que les échanges entre l’auteur du rapport et les ingénieurs logiciels Apple, mais masque tous les autres détails du bugs. Ces détails sont des commentaires de l’ingénieur, la progression du travail autour du bug, quand les ingénieurs «s’attendent» à le réparer, la version du système dans laquelle il est corrigé, et la priorité. La priorité est importante pour les bugs. ils sont considérés comme «non filtrés» s’ils ne disposent pas d’un ensemble de priorités. Les bogues avec une priorité élevée (1) sont très susceptibles d’être corrigés, alors que les bogues avec une priorité inférieure (3 ou 4) ne seront probablement jamais corrigés ».

Décrit de cette manière, le système peut sembler fonctionnel, mais de nombreux écueils en limitent grandement l’efficacité.

D’abord le bug doit être correctement catégorisé, c’est à dire renvoyer à la brique logicielle concernée, par exemple AppKit / NSTableView. Si la chose ne pose pas de problème pour les experts, il en va autrement pour le grand public qui n’a aucune connaissance des arcanes des systèmes Apple. Conséquence, certains pans « grand public » reçoivent des quantités considérables de rapport de bug, par exemple « iTunes / All ». « Ces composants sont saturés de rapport de bugs », explique Corin.

Le temps est assassin

Autre problème, ces rapports de bugs sont affectés aux différents groupes de développement, et passent par un filtre : ils sont « passé en revue » par un ingénieur qualité, qui se charge de tenter de les reproduire, et de les documenter, éventuellement en échangeant avec l’auteur du rapport de bug. Lors de ce passage en revue, une priorité est affectée au bug et, éventuellement, une période de correction. À ce stade, le rapport de bug est transmis aux équipes chargées du composant logiciel concerné. « Les bugs avec un faible niveau de priorité ne sont quasiment jamais examinés » par celles-ci, estime le développeur. Pire, devant l’accumulation de rapports de bugs, certaines équipes les ferment en masse, obligeant les utilisateurs à soumettre à nouveau des rapports de bugs sur les mêmes bugs.

Ensuite, Apple ne communique pas avec les auteurs de rapports externes. Si, par exemple, un bug est corrigé dans une version bêta d’un système, l’auteur du rapport n’en sera pas tenu informé. Il ne le sera que quand c’est une version publique qui intégrera la correction. Un peu tard, en somme, puisque l’objet des bêta est justement d’éliminer les bugs. il peut parfois s’écouler plusieurs mois, voire une année avant qu’un bug sérieux ne soit corrigé.

Parfois, c’est si lent qu’il est impossible aux ingénieurs de vérifier et reproduire le bug. Celui-ci exigerait, par exemple, l’installation d’une version antérieure des systèmes pour être reproduit. Il sera considéré comme corrigé dans ce cas…

Des pistes d’amélioration

Corin Dunn estime qu’Apple peut grandement améliorer l’efficacité de Radar, à condition d’y mettre les moyens et d’en faire une priorité. D’abord, Apple devrait faire remonter plus vite les bugs aux ingénieurs responsables, et alléger leur charge de travail pour qu’ils puissent passer le temps nécessaire au traitement des bugs. Apple derait également favoriser la communication entre les ingénieurs et les auteurs de rapport, ce qui accélérerait le mouvement.

Pour les utilisateurs, il conseille de ne pas hésiter à envoyer des rapports de bugs, y compris en doublon, les doublons étant considérés comme un indice de la fréquence du bug et accélérant dès lors leur traitement.

AUCUN COMMENTAIRE

À vous la parole !

Fermer
*
*

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.