C’était mon cas avec iTerm2 + oh-my-zsh, et on va voir comment trouver les problèmes à la source.

Identifier les causes

Je n’ai pas forcément fait attention au moment exact où mon terminal a commencé à être capricieux pour se lancer. J’ai l’impression que ça a commencé la semaine marquée par l’arrivée d’un nouveau super pouvoir du MDM sur nos machines pro. Il analysait toutes les commandes exécutées pour vérifier les bons privilèges à appliquer.

Une belle coïncidence, c’était le suspect parfait. Je l’ai un peu blâmé sans trop chercher plus loin. Et puis un jour, il est arrivé ce fameux imprévu qui permet au héros de se lancer dans l’aventure.

J’étais en pair avec un collègue pour l’aider sur une erreur autour de cocoapods et iOS. Je lui fais installer un version manager pour Ruby, on modifie son .zshrc, et on veut supprimer le Podfile.lock pour réinstaller proprement les packages. Mais dans la rapidité de l’action, il tape rm .zshrc. Aïe. Coup dur.

À ce moment-là, mon collègue est un peu dégoûté - je l’aurais été aussi. Avec rm, ça ne part pas à la corbeille, on ne récupère pas facilement ce que l’on a supprimé. Ça l’embête parce qu’il avait effectué plusieurs configurations dedans, et qu’il avait passé une heure avec la DSI pour optimiser le temps de chargement. Hop hop hop, attends. Quoi ?!

Lui aussi avait son terminal qui était long au lancement, et de mémoire, ça venait en partie de l’initialisation de nvm. Me voilà avec une piste intéressante. Je l’ai gardée dans un coin de tête, jusqu’à hier soir où j’ai fouillé les internets avec une idée de direction plus précise.

Mesurer le temps

À l’aide de deux instructions, on peut obtenir un rapport avec les différentes étapes exécutées au lancement de zsh et le temps associé.

Il suffit de modifier le fichier .zshrc pour y ajouter zmodload zsh/zprof au tout début, à la première ligne. On quitte le terminal, on le relance et on tape la commande zprof.

num  calls                time                       self            name
-----------------------------------------------------------------------------------
 1)    2        3047,39  1523,69   43,08%   2046,60  1023,30   28,93%  nvm
 2)    1        4998,69  4998,69   70,66%   1951,31  1951,31   27,58%  nvm_auto
 3)    1         821,18   821,18   11,61%    665,29   665,29    9,40%  nvm_ensure_version_installed
 4)    1         563,64   563,64    7,97%    563,64   563,64    7,97%  is_update_available
 5)    1         743,74   743,74   10,51%    180,11   180,11    2,55%  /.oh-my-zsh/tools/check_for_upgrade.sh
 6)    1         176,44   176,44    2,49%    174,59   174,59    2,47%  nvm_die_on_prefix
 7)    1         155,88   155,88    2,20%    155,88   155,88    2,20%  nvm_is_version_installed
 8)    1          93,04    93,04    1,32%     51,05    51,05    0,72%  compinit

Dans ce tableau, on retrouve le nom des étapes, le temps, le pourcentage du temps par rapport à l’ensemble, et c’est même classé dans l’ordre du plus long au plus rapide.

Sur ma machine, je vois clairement que nvm est dans le haut du panier. Plusieurs noms d’étapes semblent liées à nvm et elles prennent énormément de temps. Je vais donc optimiser le lancement de nvm, le reste me semble anecdotique. Je le ferais ou pas un jour. Sûrement jamais. :)

Améliorer l’initialisation de nvm

J’ai trouvé plusieurs moyens pour pallier la lenteur de nvm.

Supprimer nvm du .zshrc

Quand on installe nvm, il y a des instructions à ajouter dans notre configuration .zshrc. Leurs rôles sont de charger nvm, de s’assurer qu’il est à jour, de préparer l’auto-complétion, etc. C’est ce qui ralentit le lancement de notre terminal. Ces instructions ressemblent à ça :

export NVM_DIR="$HOME/.nvm"
    [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"  # This loads nvm
    [ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"  # This loads nvm bash_completion

Bon. Eh bien de manière pragmatique, on peut supprimer ces instructions de notre configuration .zshrc et le temps de lancement sera grandement amélioré. Si on n’utilise plus nvm, node et compagnie, ou très peu souvent, on n’a pas envie de pourrir l’expérience nominale de notre terminal.

Lazy loading de nvm

Une autre solution serait d’initialiser nvm uniquement lorsque l’on en a besoin. Quand on tapera une commande avec nvm, node ou npm par exemple. C’est du lazy loading. Ce serait l’idéal si on veut conserver nvm et que l’on veut éviter de ralentir le lancement du terminal.

Il est possible de le faire soi-même en créant quelques fonctions bash comme l’explique cet article. On peut aussi utiliser le système de plugin de zsh. Luke en a créé un pour nvm : zsh-nvm. J’ai opté pour cette solution.

• La première étape est de supprimer les éventuelles instructions nvm de notre fichier .zshrc (cf. partie précédente).
• On installe ensuite le plugin zsh-nvm.
• On modifie le fichier .zshrc pour ajouter zsh-nvm dans la liste des plugins.
  • La ligne ressemble à plugins=(.......).
• On indique au plugin que l’on veut du lazy loading.
  • On ajoute export NVM_LAZY_LOAD=true juste avant la liste des plugins.
• On peut ajouter l’auto-complétion si nécessaire.
  • En ajoutant également export NVM_COMPLETION=true avant la liste des plugins.

Changer de version manager pour node

Vu que nvm est le fautif et qu’il existe d’autres version manager pour node, on peut se demander s’il en existe qui sont plus rapides.

Ça semble être le cas pour fnm (Fast Node Manager). Son nom est revenu plusieurs fois pendant mes recherches et dans les commentaires de personnes qui proposaient des alternatives au lazy loading de nvm. Je ne l’ai pas essayé.

Il y a également asdf, un outil unique qui propose de gérer les versions de multiples autres outils (node, Ruby, python, …). J’en parlais dans mon article sur les version manager. Il serait plus rapide que nvm d’après ce que j’ai lu. À tester. Je pense que je finirais par me passer de mes autres version manager pour tout regrouper avec asdf.

Quelques références de contenu que j’ai parcouru :

• https://dev.to/thraizz/fix-slow-zsh-startup-due-to-nvm-408k
• https://blog.mattclemente.com/2020/06/26/oh-my-zsh-slow-to-load/
• https://broken-by.me/lazy-load-nvm/
• https://stackoverflow.com/questions/47009776/how-to-run-nvm-in-oh-my-zsh

Tout commence lorsque notre PO, vient nous voir pour nous montrer un problème avec la liste des offres mises en favoris. Pour une catégorie d’offre en particulier, l’icône favori n’est pas dans le bon état.

Première action, j’essaie de reproduire le problème. Avant de foncer dans le code, je cherche les scénarios utilisateurs qui provoquent le problème et je les note. Et ensuite, avec ça, je peux me prouver que l’anomalie est résolue en ayant écrit des tests et en rejouant le scénario avec/sans correctif. C’est un des premiers conseils que je voudrais partager dans cette histoire.

Grâce à un scénario précis, on peut également affiner l’origine du problème. Par exemple, ici, ça m’a permis de voir que le problème n’était absolument pas lié à la catégorie de l’offre. L’origine se situait dans notre cache HTTP - il nous manquait une invalidation du cache suite à une action spécifique. On corrige le problème en pair-programming et, tout content de notre avancée, on informe notre PO qu’une nouvelle version de l’application est déployée en recette. On passe à autre chose. Fin de l’histoire, tous les problèmes sont résolus.

Tous ? Non ! Un village peuplé d’irréductibles anomalies résiste encore et toujours aux développeurs. Le fil à retordre va devenir bien rigide.

À notre grande surprise, notre PO revient me voir : “je fais comme avant et j’ai le même problème, la correction n’aide pas”. Ok. Très étrange. On a pourtant bien constaté la résolution avec nos scénarios. La cause identifiée était parfaitement logique. La partie métier est très bien couverte par des tests. Je recommence le scénario sur mon téléphone, c’est OK. Qu’est-ce qui diffère entre nos téléphones ?

Frédéric a constamment le problème alors que de mon côté, je ne l’ai jamais. En creusant et en essayant diverses choses (même modèle de téléphone, s’échanger les comptes utilisateurs, …), on finit par trouver. Il télécharge l’application depuis Firebase Distribution alors que moi je l’exécute directement depuis mon IDE. On a la même base de code, mais la compilation diffère légèrement - lorsqu’une application est déployée, elle est compilée en mode release (il y a des optimisations, des règles plus strictes, etc).

Super ! On sait reproduire à 100%. Super ! Compiler en mode release signifie aussi que je me coupe de tout un tas d’outils de développeurs pour observer ce qu’il se passe. Je ne peux pas debugger avec des breakpoints, je ne peux pas lire les logs, je ne peux pas observer les échanges réseaux, et, très embêtant, les build en mode release sont bien plus long à générer que l’exécution en mode debug.

À ce moment-là, je me dis qu’on a un bon problème mystique. Je n’arrive pas à reproduire à 100% en mode debug, et on ne sait rien de la cause. C’est à mon tour de changer de mode : je passe en mode “enquête”.

Je commence par ouvrir un document pour écrire ce que je sais du contexte et du scénario qui reproduit le problème. Ça me permet de rassembler toutes les informations, de vérifier si je passe à côté de quelque chose d’évident en l’explicitant, et de pouvoir mieux communiquer. Puis je lance une multitude d’hypothèses. On a plusieurs appels HTTPs qui se déclenchent au lancement de l’application, dont la liste des favoris. Est-ce que notre backend rejette certaines requêtes parce qu’un même compte utilisateur fait trop d’appels simultanés ? Est-ce le client HTTP utilisé dans l’application ? Est-ce le cache HTTP ? Est-ce l’OS du téléphone qui empêche de faire trop de requêtes dans un trop court laps de temps ? Etc. J’essaie de ne fermer aucune porte.

Ensuite, je me lance dans des expérimentations rapides. Je cherche à valider ou invalider des hypothèses pour affiner progressivement l’origine. Pour le moment l’éventail des possibilités est trop larges. Je cherche aussi à apprendre de nouvelles informations avec les résultats de ces expérimentations.

Je commence par m’orienter sur le backend. Je veux voir ce qu’il se passe alors j’ouvre Elastic (un outils d’analyse de logs très puissant ajouté sur notre backend) et je filtre les logs sur l’identifiant de mon compte utilisateur. Tiens, la requête des favoris n’apparaît pas. Je vais voir un développeur backend pour creuser cette curiosité. On fait plusieurs vérifications, notre backend n’a pas de mécanisme pour rejeter la requête, et ce n’est pas l’infrastructure non plus. J’invalide donc l’hypothèse du backend, et je repars avec un apprentissage intéressant : la requête n’arrive pas au backend.

Je repasse sur l’application mobile. Je veux travailler l’hypothèse du cache. Au tout début, j’ai effectué un correctif mais il reste un problème. Le mécanisme dans sa globalité a un peu de complexité, je cherche un réponse stricte et binaire : est-ce que ça vient du cache, OUI ou NON ? Je désactive le cache simplement, au plus haut niveau, sur toutes les routes - il n’est plus du tout utilisé. Résultat, le problème est toujours là, l’hypothèse est invalidée.

Il faut chercher ailleurs, mais je manque d’indices. J’ai besoin de rendre l’application davantage observable. Pour rappel, en mode release, l’application n’écrit pas dans la console lorsque l’on appelle la fonction notre logger. Néanmoins, la fonction est tout de même appelée. Eh bien, je peux modifier la fonction pour stocker les logs en mémoire, et ajouter un bouton sur la page d’accueil qui me permet de me partager les logs (via un mail ou une note synchronisée dans le cloud). Je peux faire ça très rapidement, en quelques minutes.

J’insiste à nouveau sur rapide. Tout le long de mon enquête, je veux une boucle de feedback très courte, je ne cherche pas à coder pendant 3h un truc over engineered ou trop clean ou trop future-proof, ce n’est pas le but. Je ne conserverais aucun code à la fin. Lorsque j’aurais quelque chose qui fonctionne et qui aura corrigé le problème, je recommencerais proprement de zéro en sachant où je dois aller.

Maintenant que j’ai accès à des logs provenant de l’application, je constate que la requête HTTP ne part pas. Ça confirme ce qu’on a pu voir sur le backend, et le besoin d’avoir plus d’informations pour comprendre pourquoi la requête ne part pas. J’ajoute alors davantage de logs, pour voir si chaque brique est bien appelée. Middleware, repository, action, etc. Tout le cheminement est bien fait, et ce n’est pas surprenant vu que le use case est couvert par des tests.

Il y a quelque chose de plus fin à trouver. Je mets des logs juste avant et juste après l’appel HTTP. Bingo. Une bizzarerie se met en évidence : le log après l’appel HTTP n’est jamais appelé, et il n’y a pas non plus d’exception soulevée. La fonction semble ne jamais rendre la main. Première hypothèse, on pense que c’est dû à la co-existance de deux clients HTTPs (le temps d’une migration douce). Alors on migre vulgairement ces quelques requêtes sur le même client. Invalidée. On commente les appels réseaux au démarrage, sauf ceux des favoris. Invalidée.

Je saute dans le temps pour arriver à la fin. On fini par identifier la source du problème et y apporter une correction. On comprend au passage qu’il y avait deux problèmes distincts, le premier correctif était aussi nécessaire. Tout fonctionne parfaitement. Victoire, par toutatis !

Au travers de cette histoire, j’ai essayé de mettre en lumière certains aspects. L’utilité d’avoir des scénarios de reproduction précis, tout d’abord, pour vérifier que l’anomalie est corrigée, écrire des tests, éliminer/affiner de premières hypothèses. Puis le fonctionnement en expérimentations rapides. On essaie d’avoir un tas d’hypothèses, d’en sélectionner une à la fois, de valider ou invalider rapidement avec des actions simples, d’apprendre de nouvelles informations pour la suite de l’enquête.

Il y a aussi une notion d’observabilité. On a besoin de comprendre ce qu’il se passe pendant qu’un logiciel est utilisé. Côté backend, on est très bien équipé avec la suite ELK par exemple. Mais côté mobile, Crashlytics n’est pas du tout suffisant. Les crashs ne sont qu’un sous-ensemble des problèmes qui peuvent arriver, et l’interface est loin d’être aussi puissante qu’ElasticSearch. On peut s’améliorer dans ce domaine tout en respectant les contraintes liées à l’écosystème mobile.

À de multiples reprises, j’étais également en pair-programming, avec plusieurs collègues. Rien ne vaux plusieurs cerveaux, plusieurs idées, visions, façons de faire.