Une tendance généralisée dans le développement informatique est l'utilisation d'environnements de développements (IDE,
Integrated Development Environment), comme Eclipse, dont je vous conseille par ailleurs la 3.4 «
Ganymede ». Ces outils apportent par exemple la syntaxe colorée, la navigation entre fichiers, mais aussi l'aide à la saisie et la compilation à la volée, parmi des milliers d'autres fonctionnalités (je n'exagère pas).
Je pense qu'il faut distinguer entre ces fonctionnalités par leur type d'interaction avec l'utilisateur :
- sans interaction : la coloration syntaxique, par exemple. La frappe suit son cours, et le résultat est formaté à l'écran.
- interaction au cours de la frappe : vérification de la syntaxe, aide à la saisie, compilation en tâche de fond... Ces assistants se déclenchent certes de façon asynchrone (ouf !), mais pompent quand même des ressources, aussi bien sur la machine que dans le cerveau de l'utilisateur (les fenêtres pop up ne sont jamais neutres pour un cerveau humain ;-)), ce qui au final freine le rythme naturel de la frappe... tout en accélérant par ailleurs la saisie des noms de classes, de méthodes, de variables. Avec une utilité à mesurer pour chacun, donc.
- interaction par décision de l'utilisateur : lancer l'exécution de tests ou d'une application par exemple. Cela se fait en général par un raccourci-clavier, plus rapide qu'un clic souris. Cette interaction ne perturbe pas le flot de développement : l'utilisateur déclenche de lui-même les événements.
Je ne parle pas des interactions de type
Wizard, où l'utilisateur suit une série de formulaires.
Ajoutons un quatrième type, l'interaction par déclenchement en ligne de commande d'un script par l'utilisateur. En gros, je vais dans ma console, je tape ma commande (disons : mvn clean install), elle s'exécute, et je me rends le plus souvent dans une autre application pour voir le résultat (disons : un éditeur de texte, pour voir les logs).
Cette dernière interaction est la plus primitive et naît de la nécessité (pas d'intégration continue sans scripts autonomes, par exemple), et pourtant c'est celle qui est la plus perturbatrice, car on navigue entre des contextes différents, avec leurs IHMs et leurs temps propres. Là où les IDEs font énormément gagner de temps, c'est bien sur la suppression des interactions en ligne de commande.
Prenons par exemple un script qui fabrique et déploie une application web (je me place dans le cas où le serveur web n'est pas embarqué dans l'IDE, cas le plus courant pour moi). Le scénario classique est le suivant :
- IDE : finir de modifier le code
- console : lancer le script en ligne de commande de fabrication et de déploiement
- navigateur web : voir le résultat
Pour gagner en puissance, nous pouvons faire la chose suivante qui nous évite le passage par la console :
- IDE : finir de modifier le code
- IDE : lancer le script externe par un raccourci clavier (voire obliger son lancement automatique après toute modification)
- navigateur web : voir le résultat
Mais je pense que c'est quand même une perte cognitive : on demande à un contexte (l'IDE) de réaliser quelque chose, qui peut d'ailleurs mettre du temps, dont on verra le résultat dans un autre contexte (le navigateur). Cognitivement on est déjà dans le résultat (on sait ce qu'on demande au final : un résultat dans le navigateur), mais du point de vue de l'outillage on est encore dans la préparation (l'IDE).
Pour moi la bonne séquence est la suivante :
- IDE : finir de modifier le code
- navigateur web : rafraîchir la page en cours (touche F5), ce qui lance le script externe, puis affiche le résultat, sans changer de contexte
J'appelle ça le « facteur F5 » ("The F5 Factor" en anglais). Ce principe est orienté
contexte de résultat, et non environnement de développement.
Si possible, disposer de deux machines, une pour le code, une pour le navigateur : ainsi il ne s'agit
que d'appuyer sur F5 sur le clavier d'à côté. Pas d'autre manipulation du genre Alt-TAB. Aucun changement d'application, de perspective, de vue, de fenêtre, de
space... ni aucun
switch mécanique : on tourne simplement la tête.
Dans ce modèle, le serveur web doit évidemment être sur la première machine, ou en tout cas avoir accès aux fichiers qui ont été modifiés.
J'essaie de faire en sorte que mes outils de développement web, notamment mes outils de maquettage, mais aussi mes outils de validation, appliquent le « facteur F5 ». Cela pose de nombreuses questions d'intégration et de réactivité : sur la parallélisation des traitements, sur l'optimisation, sur la gestion des fichiers, etc. mais aussi sur le découpage des composants : s'il faut dérouler ne serait-ce qu'une partie de scénario fonctionnel pour arriver sur la page dont on veut valider le HTML, on n'est plus dans le « facteur F5 ». C'est dire s'il faut parfois pour se donner les moyens réarchitecturer entièrement un projet, et notamment repenser les phases de maquettage.
Ces outils sont évidemment couplés à des scripts autonomes (toujours pour l'intégration continue), mais les scripts encapsulent les outils, et non le contraire.
Au final, un très grand confort de développement : modifier deux lignes de Java, et voir le résultat quasiment immédiatement dans le navigateur. On se croirait en PHP ?... En fait c'est encore mieux, car si toutes les pages du site sont testables en appliquant le « facteur F5 », le temps gagné est inestimable. Par ailleurs il s'agit là d'une méthodologie, et c'est donc transverse aux technologies.
Pour mémoire, mon dernier outil en date qui applique le « facteur F5 » est un lanceur d'applications (Java) depuis une page web, qui en affiche ensuite les résultats à l'écran : résultats images, SVG, HTML ou texte. À utiliser en phase de maquettage, en appuyant sur... F5.
(des pingouins qui se mettent à l'eau et s'éclaboussent, quel rapport ? me direz-vous)
(photo non contractuelle)
