Au fil des années, j'ai assemblé et peaufinné un workflow dont je suis enfin satisfait. Il y a eu beaucoup d'essais, d'erreurs, d'abandons, de réadoptions. Bref, cela a été un long processus itératif pour trouver ce qui me convient le mieux. Aujourd'hui, ce workflow est composé des outils principaux suivants :

• bash ;
• tmux ;
• VSCodium (+ extension Vim).

En assemblant tous ces composants, je peux être productif et travailler confortablement. Je vous propose d'explorer plus en détail mon workflow dans la suite de cet article.

Contexte et besoins

Commençons d'abord par me présenter et exposer mes besoins. Je suis un développeur travaillant dans des environnements Linux. Je suis souvent amené à éditer du code et invoquer diverses commandes. En simplifiant au maximum, j'ai principalement besoin des éléments suivants sur ma machine lorsque je travaille :

1. Un terminal (avec un shell)
2. Un éditeur de texte / IDE

Mes outils

Dans cette section, je présente chaque outil (Quoi), Pourquoi je l'utilise et Pourquoi je n'utilise pas une alternative populaire.

1. bash

• Quoi :

  Bash est un shell UNIX conforme à Posix. Rien de spécial à ajouter.

• Pourquoi :

  J'ai choisi bash par absence d'une alternative convaincante. Cf. la section suivante.

• Pourquoi pas zsh, fish, etc. :

  Bash est le shell par défaut sur bon nombre de distributions Linux. D'ailleurs, la plupart des scripts shell que l'on trouve sont en fait des scripts bash. J'utilise donc bash pour sa pérrenité et son ubiquité. J'ai déjà essayé des shells alternatifs mais aucun ne propose de fonctionnalités primordiales justifiant un changement permanent.

2. tmux

• Quoi :

  Tmux est un multiplexeur de terminaux. Il permet l'utilisation de plusieurs terminaux virtuels dans une seule fenêtre de terminal. Tmux propose aussi un système de sessions, lesquelles peuvent être détachées et continuent de fonctionner en arrière-plan.

• Pourquoi :

  Tmux permet de créer des sessions de travail. Ces dernières ont deux avantages principaux :

  a. Gestion des fenêtres et panneaux

  Pour illustrer ce point, prenons l'exemple d'un projet nécessitant d'exécuter divers processus en parallèle :

  • Un serveur frontend ;
  • Un serveur backend / API ;
  • Git (pour traquer le code source).

  Au lieu d'ouvrir un terminal par processus, une session tmux peut être utilisée. Lesdits processus peuvent être invoqués dans une même session et être arrangés en fenêtres et/ou panneaux, selon les préférences.

  Si le besoin éphémère de changer de contexte survient, la session peut simplement être détachée et la tâche annexe effectuée. La session peut par la suite être réattachée afin de reprendre le travail.

  b. La persistance

  Cette caractéristique est très intéressante dans le cas des machines distantes auxquelles on se connecte via SSH. En effet, lors d'une connexion SSH standard, si l'on vient à être deconnecté — un problème réseau par exemple —, le processus en cours d'exécution est tué.

  Dans le cas d'une session tmux, cette dernière est tout simplement détachée et le(s) processus continue(nt) en fond. Il est possible de réattacher la session par la suite lors de la reconnexion SSH.

• Pourquoi pas GNU Screen :

  Selon moi, tmux est plus simple à prendre en main, autant au niveau de sa configuration que de sa scriptabilité.

3. VSCodium (+ extension Vim)

• Quoi :

  Cette partie est un peu plus complexe à décrire. Pour comprendre, il faut parler de VSCode, VSCodium, Vim et VSCodeVim ; décomposons...

  a. VSCode, ou Visual Studio Code, est un IDE et éditeur de code, développé par Microsoft. C'est un des IDE modernes les plus populaires à travers le monde et il dispose d'un large panel d'extensions.

  b. VSCodium est une distribution de VSCode exemptée de la télémétrie et la marque Microsoft.

  c. Vim est un éditeur de texte extrêmement personnalisable fonctionnant dans le terminal. Il existe depuis plus de trois décennies maintenant — plus de quatres si on compte son ancêtre Vi.

  d. VSCodeVim est une extension permettant d'introduire le comportement de Vim dans VSCode / VSCodium.

• Pourquoi Vim (en tant que concept) :

  

  De premier abord, Vim (et tout ce qu'il représente) peut paraître ancien, obsolète et inadapté au développement moderne ; pourtant il est très pertinent.

  Vim se différencie par son paradigme innovant : le fonctionnement modal ; ce qui pose bien souvent des problèmes aux débutants. C'est cependant ce qui en fait toute sa force.

  Vim possède son propre langage de touches, à savoir une langue avec une grammaire et un vocabulaire propres. Dans le mode "NORMAL" (le mode par défaut lorsque Vim est ouvert), il n'est pas possible d'écrire du texte. C'est dans le mode "INSERTION" que l'on peut faire cela, comme dans un éditeur classique. En revanche, le mode "NORMAL" permet de naviguer dans le document et de manipuler son texte.

  On peut par exemple supprimer tout un paragraphe (par rapport à la position du curseur) à l'aide du raccourci dip:

  • d est le verbe d'action et signifie "delete" (supprimer) ;
  • i est un modificateur qui signifie "inside" (dedans, à l'intérieur). Il permet de préciser ce qui suit.
  • p est le sujet et signifie "paragraph" (paragraphe 🙃).

  La phrase suivante est donc construite : "delete inside paragraph", soit "supprimer l'intérieur du paragraphe". Et cela n'est qu'un exemple parmis tant d'autres.

  Avec le temps, la mémoire musculaire se développe, au point de pouvoir naviguer et éditer le code à la vitesse de la lumière. L'effort cognitif à fournir entre la pensée et l'action devient quasiment nul.

  De plus, les touches Vim sont répandues dans de nombreux autres outils.

• Pourquoi Vim dans un IDE (et pourquoi pas autre chose) :

  Cela fait maintenant un bon nombre d'années que j'utilise Vim. Avec le temps et l'expérience, il m'est devenu compliqué d'utiliser un autre éditeur de texte. J'affectionne énormément le fonctionnement modal que Vim propose et les gains de productivité qui en découlent.

  Pendant longtemps, j'ai utilisé Vim exclusivement via sa forme terminal. Cela signifie : passer un bon paquet de temps à le peaufinner afin qu'il me corresponde en tout point. Au bout d'un temps, l'effort à fournir est devenu trop élevé par rapport au gain constaté. En fait, la complexité réside dans le fait de maintenir une configuration homogène, cohèrente et intuitive.

  Lassé de cette expérience, j'ai opté pour le choix suivant : utiliser un IDE moderne enrichi du comportement modal de Vim. Cela permet de combiner — à mon sens — le meilleur des deux mondes : intuitivité (grâce à l'IDE) et boost de productivité (grâce à Vim).

• Pourquoi VSCode / VSCodium :

  Il n'y a pas de raisons particulières qui m'ont poussées à choisir VSCode / VSCodium plutôt qu'un autre IDE. J'ai simplement accroché au design et à la facilité de prise en main.

Dotfiles

Les outils cités à travers ce post sont configurables via des fichiers de configuration, aussi appelés dotfiles — simplement parce que leur nom est souvent préfixé d'un point. J'utilise un dépôt Git pour traquer et synchroniser mes dotfiles à travers mes différentes machines. Cette approche a deux avantages :

• Versionner les fichiers et ainsi garder une trace de leur évolution ;
• Offrir un environnement de travail consistant et facilement réplicable.

Prévenir des douleurs articulo-musculaires

En parallèle de ce peaufinnement de workflow, j'ai fait l'acquisition d'un clavier mécanique ortholinéaire — le Planck EZ. Bien que ce clavier soit très onéreux, je pense honnêtement que c'est mon meilleur investissement depuis longtemps. Ce dernier m'a forcé à apprendre à taper au clavier correctement en utilisant chaque doigt des deux mains.

Avant cet achat, je souffrais de douleurs non négligeables au niveau des avant-bras et des poignets, causées par des mouvements répétitifs parasites. Ces douleurs pouvaient être aiguës, au point de m'empêcher de travailler.

Depuis que j'ai appris à correctement taper au clavier, mes mouvements de bras et de mains sont réduits au minimum. En plus, l'utilisation de la souris est presque absente de mon workflow ; j'ai défini tout un tas de raccouris claviers. Cela minimise encore plus les mouvements parasites et conduit à prévenir la douleur.

Conclusion

Les outils et leur configuration relèvent de l'appréciation personnelle — les goûts et les couleurs…. Un workflow donné ne peut pas correspondre à tout le monde ; c'est un long processus itératif et personnel.

Les connaissances que j'ai regroupées ici vous seront peut-être bénéfiques — ou peut-être pas. Je vous encourage à vous pencher sur la question et partager vos découvertes.