Aventure de développeur : un déboggage de débogueur
Quand on a besoin de voir ce qui se passe à l’exécution du code, le débogueur est un outil formidable. Dans le cadre d'un développement iOS, on utilise le débogueur LLDB fourni avec Xcode. On met un point d’arrêt là où il semble y avoir un soucis et on peut ensuite interagir directement avec le code au moment de l’exécution. C’est un outil formidable, sauf quand il ne fonctionne plus. Et c’est exactement l’aventure qui m’est arrivée cet été : une saga pleine de péripéties qui se termine par une fin heureuse, comme on les aime.
Nous étions donc avec un client au printemps quand nous avons décidé de migrer notre code sur une version plus moderne de Xcode, en l’occurrence la version 13.4. Tout se déroulait à merveille, jusqu’à ce que la machine se grippe : le débogueur LLDB ne voulait plus débogguer une partie du code. D’après les forums des développeurs Apple, le problème datait un peu et concernait un public assez limité comme je l’expliquerai plus loin. Plutôt que de perdre un temps plus précieux que les bénéfices de Swift 5.6, nous avons choisi de repousser cette migration.
Le début de l’aventure
Tout cela ne m’a pas empêché de creuser un peu plus ce sujet fort intrigant sur mon temps personnel. J’ai donc conçu un projet de démo permettant de reproduire le problème à coup sûr en limitant la quantité de code environnant qui pourrait brouiller la résolution.
En premier lieu, pour reproduire ce problème, il faut utiliser LLDB. En effet, plutôt que de mettre un point d’arrêt, nombre de développeurs se contentent d’exécuter la commande print()
un peu partout dans le code et recompilent le projet jusqu’à ce que la source du problème soit débusquée. Également, il faut que l’app en question utilise des frameworks ou bibliothèques internes ou externes (CocoaPods inclus) et que le développeur souhaite débogguer ce code. Il faut aussi que ce code soit compilé statiquement : c’est généralement un avantage en termes de performances. Enfin, cela ne concerne pas les paquets Swift qui sont la manière officielle de modulariser le code selon Apple et qui bénéficient d’un meilleur accompagnement du constructeur. En gros, sont concernés les professionnels qui sont prêts à mettre les mains dans le cambouis.
J’ai donc conçu un projet décliné selon les différents cas de figure :
- une bibliothèque statique
- un framework compilé statiquement
- un pod interne configuré pour générer un framework compilé statiquement
- un code minimal utilisant Xcode en lignes de commande pour la compilation.
En parallèle, j’ai aussi créé une déclinaison utilisant des paquets Swift afin de m’assurer que cela ne vient pas de mon code Swift.
À ce stade, tout fonctionne jusqu’à Xcode 13.2.1. Ensuite, à partir de Xcode 13.3, ça ne fonctionne plus. J’ai donc l’exemple parfait, facile à débogguer et facile à comprendre.
La WWDC22 à la rescousse
Le printemps, c’est aussi l’arrivée de la WWDC et du nouveau Xcode, une arrivée à point nommé. Et là, première surprise : tout fonctionne de nouveau avec Xcode 14. Le premier automatisme est donc de se dire que c’était un bogue de Xcode 13.3 et 13.4. Mais en même temps, Apple a publié une session intrigante sur le déboggage du débogueur. Quel paradoxe ! D’un côté, le problème disparait avec Xcode 14. De l’autre, cette session fait état du problème que j’ai rencontré et apporte — au moins en partie — la solution.
"Avant d’aller geindre comme un enfant gâté"
Et aussi de crier au bug, donc...
La phrase "ca marchait toujours comme ca ya pas de raison que.." et une fois resolu "putain ils ne pouvaient pas laisser en l'etat"
Ben non, il faut evoluer, la technique de la roue carrée ou de la roue ronde, ca a pas ete simple d'échanger mais après un certain temps d'adaptation on y gagne à coup sûr. et le pire c'est que beaucoup de choses sont accessibles sous reserve de creuser le sujet un peu.
si vous n'aviez pas décidé de voir ca plus précisément hors de votre boulot pur, vous n'auriez jamais decouvert la solution, et le prochain projet pourra en profiter. alors que (trop) d'autres fois on aurait eu " on a essayé une fois on a fait marche arriere, now on ne le fait plus" (suivi généralement d'un commentaire genre "apple c'est plus ce que c'etait comme du temps de jobs" ) ce qui est logique quand on ne veut pas passer plus que ses heures de travail sur un sujet.
Ce n'est pas un combat simple, on doit negocier avec sa famille proche, l'envie de se divertir, les charges de travail, les fins de semaine, les amis et j'en oublie, mais c'est, a mon avis, la vraie morale de l'histoire: soit on veut aller de l'avant et cela demande des sacrifices, soit on ne veut pas, ok ca se defend, mais on ne se plaint pas!!!!!!!!!!!!!
Merci Florent, dès le titre de l'article je me suis douté que ca venait de vous ^^
C'est vrai que la vie personnel en a toujours fait les frais. Mais c'est le métier qui veut ça. Pour les agriculteurs ou ceux qui travaillent de nuit, c'est autre chose !
Et il y a aussi et avant tout la passion, qui comme toute passion est dévorante. L'important est de faire la part des choses.
Personnellement, je limite ce temps passé à 5 heures par semaine. Et ce n'est pas prioritaire au reste, sauf s'il y a un enjeu professionnel majeur. ça oblige à mieux s'organiser, de fait.
@FloMo
je ss un peu bourrin sur ce sujet, je considere que la vie de famille ou personnelle sans boulot est condamnée au désastre, humainement comme financierement. Alors évidemment c pas simple (et limiter à 5h/sem c pas mal) et dans "boulot" j'ai ajouté les vies associatives, parent d'eleve, etc.. mais le coeur, c'est le metier.
Tout un sujet, loin de celui de cet excellent temoignage-article ;)
Merci Flomo !
@raoolito
Avec plaisir. 😉
@raoolito
Si c’est une passion, on sort un peu du cadre professionnel pur : de la même façon que l’on peut prendre du plaisir dans un loisir, une activité avec sa/son conjoint(e), ses enfants, ses amis… on peut prendre du plaisir sur une activité « professionnelle » qui déborde. Par contre, c’est un « plaisir solitaire » et il faut faire attention à ce que cela n’impacte pas trop les autres (amis, enfants…).
D’un autre côté, un travail informatique devrait toujours proposer du temps de veille sur son temps « officiel ». Personnellement, je passe entre 1 à 2 heures / semaine (mais pas toutes les semaines, cela dépend de la charge prioritaire) pour faire cette veille. Par ailleurs, tout travail (informatique ou non) doit aussi prévoir du temps d’entretien de ses outils sur ce temps de travail « officiel »…
@Derw
Oui effectivement
Mais c'est la théorie ;)
@raoolito
Dans la pratique, j’ai toujours eu ce temps chez mes clients à contrats longs (plus d’un mois). Chez mon client actuel il y a une ligne d’imputation « veille » dans le système de saisie du temps de travail. Et la seule fois où ce n’était pas prévu, j’en ai parlé, et cela n’a pas posé de problème.
Merci pour ce retour d’expérience 👍🏻
😊
Si ça vous plait, je pourrais en faire d'autres.
Par curiosité, à combien de temps s'est élevé l'investissement sur le temps personnel pour ce bug ?
@Nebukad
Entre 10 et 15 heures au total je dirais. Lissées sur plusieurs semaines.
@FloMo
Merci pour ce retour d'information et pour l'article. Vraiment intéressant.
Personnellement je n’ai jamais eu de réponses à un ticket déposé sur un bug iOS 🤷♂️ et ce n’est pas faute de les documenter avec des captures d’écran et/ou des snipets de codes (ce qui n’empêche que parfois ils sont résolus. Mais le ticket reste désespérément ouvert).
Je me demande comment ils traitent leur ticket. Comment sont choisis ceux qui sont traités (car il y a de toute évidence une forme de sélection qui est opérée)
@Nico_Belgium
Ça ne marche pas à chaque fois, hein !
J’ai quelques tickets en attente depuis des lustres.
Ce qui est sûr, c’est que le boulot doit être prémâché et toutes les alternatives possibles étudiées.
Ensuite, il y a aussi la fréquence du bug qui rentre en considération.
Et la forme compte aussi. Si on arrive d’emblée avec un ton accusateur et/ou campé sur ses positions, c’est mort.
Article passionnant même si j’ai du mal à saisir certaines subtilités mises en avant, n’étant pas développeur. Mais c’est quand même agréable à lire et c’est ça la force d’un récit bien écrit.
Ça doit être cette clarté et concision qui ont fait qu’Apple se soit penché sur le problème. 👏
@gwen
Merci. 🙂
@gwen
Exactement le même avis. Pas développeur donc la partie technique bof, mais le rédactionnel est parfait, un plaisir à lire et découvrir une tranche de vie de développeur.
Super article, j’espère que l’on en aura plusieurs de ce type.
Merci. C'est noté.
Pour moi qui suit resté au C++ tout cela me parait très / trop développé 🤢