L'art de l'aiguisage
Chaque artisan commence son travail avec un ensemble d’outils de base de bonne qualité. Un menuisier peut avoir besoin de règles, de calibres, de quelques scies, de bons rabots, de ciseaux fins, de forets et d’entretoises, de maillets et de pinces. Ces outils seront choisis avec soin, seront construits pour durer, accompliront des tâches spécifiques avec peu de chevauchement avec d’autres outils et, ce qui est peut-être le plus important, seront parfaitement adaptés aux mains du menuisier en herbe.
— Dave Thomas, Andy Hunt. « The Pragmatic Programmer »
Ainsi commence le troisième chapitre de « The Pragmatic Programmer » écrit par Dave Thomas & Andy Hunt. Le propos avancé par les auteurs porte sur l’importance du choix de ses outils. En tant que développeur, nous devons faire face à des situations demandant des compétences variées et pour y répondre, mieux vaut être bien outillé.
De nombreux développeurs font le choix de l’outil unique multi-usages tout intégré qui fait tout ce dont ils ont besoin et même ce dont ils pourraient peut-être avoir besoin un jour, sait-on jamais. Dave Thomas & Andy Hunt conseillent au contraire de prendre la posture de l’artisan logiciel, en commençant avec un nombre restreint d’outils génériques, et de nous familiariser avec ceux-ci ; avec le temps, d’y ajouter d’autres outils parfaitement adaptés aux situations qui se présentent à nous, apprendre à les maitriser, à les aiguiser, et chemin faisant, en faire une extension de nous même, de sorte que leur utilisation devienne fluide et naturelle.
Les outils amplifient votre talent. Plus vos outils sont adaptés et plus vous savez comment les utiliser, plus vous pouvez être productif.
— Dave Thomas, Andy Hunt. « The Pragmatic Programmer »
J’ai depuis longtemps adopté ce principe, préférant par exemple l’apprentissage de Vim et son paramétrage par petites touches à l’utilisation d’un IDE auquel il eut fallu me plier. Il en va de même pour awk, un outil taillé dans un but précis et qui rempli à merveille sa fonction depuis plus de 30 ans ! Notez en passant que bon nombre d’outils répondant à ce principe ont été mis au point il y a plusieurs décennies et sont toujours d’une grande aide aujourd’hui : awk, sed, grep, les regex… Apprendre à les maîtriser est dès lors un investissement pour le futur !
Un cas d’étude
Cependant, il est un outil qui a vu le jour en 2005 et qui est entré dans le quotidien de la majorité des développeurs à ce jour : Git. Et force est de constater que la courbe d’apprentissage de cet outil est plutôt ardue ! C’est pourquoi j’ai été séduit par GitKraken dès 2015, qui, doté d’une interface graphique tout droit sortie de Tron, offrait la possibilité d’embrasser d’un seul regard l’état d’un projet versionné avec Git. Ça a été une révolution dans mon usage et ma compréhension de Git. Ceci étant, je suis resté méfiant vis-à-vis du caractère magique que pouvait prendre la moindre interaction via cette interface, et je jonglais régulièrement entre la ligne de commande et GitKraken. Un premier indice que l’outil ne m’était pas tout à fait adapté.
Et puis, suivant l’usage qui veut qu’un projet utile est un projet actif, qu’un projet actif est un projet qui évolue, et qu’un projet qui évolue doit se voir ajouter sans cesse et jusqu’à l’écœurement de nouvelles fonctionnalités, GitKraken a grossi. Multipliant les intégrations en tout genre, ajoutant la génération de frises temporelles et la gestion de kanban, GitKraken est devenu bouffi. Son lancement est d’une extrême lenteur, tout comme l’ouverture d’un projet. À trop vouloir en faire, l’outil s’effondre sous son propre poids.
Retour à l’essentiel
C’est en faisant ce constat que j’ai décidé qu’il me fallait peut-être revoir ma façon d’utiliser Git. Depuis 2015, ma pratique a évolué et je suis maintenant plus à l’aise avec Git en ligne de commande. J’ai quelques alias — pas forcément les mêmes que ceux de mes collègues — qui me facilitent son usage au quotidien, mais je ne suis pas totalement prêt à me passer d’une interface, notamment pour préparer mes commits, découper les hunks, faire de l’exploration, et d’autres petites choses qui tirent profit d’une vision d’ensemble.
Puis je me suis rappelé l’existence de ce qui me semble aujourd’hui être le parfait compromis, j’ai nommé Tig.
Tig est une interface en mode texte pour Git basée sur ncurses. Elle fonctionne principalement comme un navigateur de dépôt Git, mais peut également aider à préparer finement des commits et agir comme un pager pour la sortie de diverses commandes Git.
Ici pas de menu, pas de boutons, pas de souris (ou presque), tout se fait au
clavier. Il va donc falloir un petit temps d’adaptation avant de se sentir à
l’aise pour naviguer au sein de l’application, mais le pli est vite pris. Et
puis on est un peu guidé, et ce de deux manières. Tout d’abord, un panneau
d’aide peut être affiché à tout moment en pressant la touche h. Et ensuite, en
bas de chaque vue, la barre de statut nous donne un certain nombre
d’informations et nous guide dans les actions à réaliser.
Ainsi accompagné, la prise en main s’en trouve grandement simplifiée. Et ce qui au départ aurait pu paraitre austère à qui n’est pas familier des TUI, se trouve en réalité être une force tant la navigation se fait fluide et quasi intuitive dès les premières heures d’utilisations !
Mais la grande force de Tig, c’est qu’il est entièrement configurable. Absolument tout est configurable. Non seulement il est possible d’afficher ou de masquer des informations selon vos préférences, de choisir l’apparence de l’arbre de commits, mais surtout il est possible d’ajouter ses propres actions, ses propres commandes, voire de modifier celles prévues par défaut !
Au moyen de commandes de liaison, les touches peuvent être associées à une action lorsqu’on les presse dans un contexte donné. La syntaxe est :
bind keymap key action
Voici quelques exemples :
# Passer rapidement au hunk suivant dans la vue stage avec la touche entrée
bind stage <Enter> :/^@@
# Désactive le comportement par défaut de la touche G
bind generic G none
# Commande externe définie par l'utilisateur pour modifier le dernier commit
bind status + !git commit --amend
# Commande interne définie par l'utilisateur qui recharge ~/.tigrc
bind generic S :source ~/.tigrc
# Cherry-pick le commit sous le curseur depuis la vue principale (avec confirmation)
bind main C ?git cherry-pick %(commit)
# Crée un commit déclaré comme étant un correctif de celui sous le curseur
bind main = !git commit --fixup=%(commit)
# Rebase interactif depuis le commit sous le curseur
bind main <Ctrl-R> !git rebase --autosquash -i %(commit)
# Crée une nouvelle branche avec une invite personnalisée
bind main B ?git checkout -b "%(prompt Enter new branch name: )"
# Affiche les statistiques de commit de l'auteur sous le curseur
bind main U +sh -c 'git --no-pager shortlog -s --author="$(git show -s --format=%aE %(commit))" </dev/tty'
L’idée ici n’est pas de faire un tour d’horizon complet de l’outil, mais de vous
donner un aperçu de son potentiel. Si vous souhaitez tenter l’expérience, un
fichier de configuration est disponible dans /usr/local/share/tig/examples/,
libre à vous de vous en inspirer pour créer votre propre ~/.tigrc.
Les possibilités offertes par Tig n’ont de limite que votre imagination ! Grâce à cela, vous pouvez adapter l’outil à vos besoins, par petites touches. Pratiquer l’art de l’aiguisage jusqu’à obtenir l’outil qui vous correspond parfaitement, celui que vous maitrisez parce que vous en comprenez le fonctionnement et les subtilités. Et n’oubliez pas :
Passez du temps à apprendre à utiliser vos outils, et à un moment donné, vous serez surpris de découvrir que vos doigts se déplacent seuls sur le clavier, manipulant le texte sans y penser consciemment. Les outils seront devenus des extensions de vos mains.
— Dave Thomas, Andy Hunt. « The Pragmatic Programmer »