La clé de la productivité des dev: un environnement de dev le plus simple possible
Marre des usines à gaz quand on bosse en local !
Il est 00:16, cela fait longtemps que je n’ai pas publié sur le blog. Plus le temps, plus trop la motivation aussi pour être honnête. Nouveau concept: je vais tenter d’écrire cet article en quelques dizaines de minutes pour ensuite prendre un repos bien mérité.
Les dev, chez vous, comment ils travaillent en local ? Combien d’outils doivent-ils installer et démarrer, combien de scripts doivent-ils lancer avant de pouvoir travailler sur leurs applications ? Sûrement, comme partout, beaucoup trop.
Vous arrivez dans votre nouvelle entreprise. Onboarding. Présentation de l’équipe. Votre première tâche arrive. Rajouter une petite fonctionnalité dans un projet. Git clone. Ah, il y a une doc dans le README sur comment installer les outils nécessaires pour travailler sur le projet. Vous commencez à lire. Un frisson vous traverse. Goutte de sueur qui coule sur le front. Un lointain souvenir du passé. Vous avez déjà vécu cette situation, avant, durant l’onboarding de votre précédente entreprise. Et durant l’onboarding de celle d’encore avant. Vous savez ce qui vous attend. Configurer l’environnement local.
Packages à installer. Scripts shell à récupérer et à lancer. Variables d’environnements à configurer. Boîtes à outils construites en interne à télécharger. Vous copiez-coller les commandes qu’on vous dit d’exécuter. Ca a l’air de faire des trucs. Tiens, une erreur. Vous coincez. Une heure. Deux. Vous demandez de l’aide. Cette erreur est "normale", elle est là depuis deux ans, vous pouvez passer à la suite. Ici, la doc est fausse, faut lancer une autre commande pour pouvoir build le projet. Personne sait comment ça marche, mais ça marche. La doc s’arrête là, la suite du setup est de la tradition orale qu’un collègue vous expliquera.
Vous voulez lancer les tests. Docker pour les base de données. Vous êtes sur Mac M1, merde. Pour tester votre application, il vous en faut aussi 5 autres pour lancer des tests end-to-end, microservices ftw. De nouveaux scripts plus ou moins maintenus pour cloner tout ça, tout démarrer en parallèle. C’est cassé, un des services ne démarre plus pour une raison obscure. Vous demandez, suppliez sur Slack vos collègues de vous aider. Personne n’a jamais eu cette erreur, pas de chance.
C’est bon ça marche. Vous lancez les tests. Ca passe pas. Ah, on vous dit que les tests demandent d’initialiser des données dans la base de données dans docker compose. Tiens, le dump sql est dispo ici, charge le avec ce script.
On vous souffle dans l’oreillette que des gens POC Minikube pour lancer toute la stack en local. Ca devrait simplifier les choses dans le futur. Il paraît.
On est jour 3. Vous n’avez encore rien fait. Votre seule envie ?
Ca tombe bien, c’est ce qu’il faut faire.
Productivité = simplicité
L’équation est simple: chaque nouveau outil à installer, chaque variable d’environnement à définir, chaque action à réaliser pour démarrer ou tester un service en local nuit à la productivité des développeurs. Quel dev n’a pas rencontré les problèmes décrits précédemment ?
Pourtant, tout cela est de la pure complexité accidentelle. Il n’y a aucne raison valable pour avoir une telle complexité sur un environnement de développement. Vous ne devriez avoir besoin que des outils du langage que vous utilisez, et éventuellement docker (et docker-compose) pour démarrer quelques dépendances types base de données SQL pour des tests d’intégration. C’est tout
Vous faites du Go ? Il vous faut la CLI go. Il vous faut quelques linters standards comme gofmt et golangci-lint. Vous lancez les tests avec go test. Vous buildez avec go build. FIN
Vous faites du Java ? Vous installez le JDK, Maven. Vous lancez les tests avec mvn test, vous buildez avec mvn package ou équivalent (tbh j’ai pas fait de Maven depuis quelques années). FIN
Du Clojure ? Il vous faut le JDK, leiningen. lein test, lein uberjar. FIN
Du Rust ? cargo test, cargo build. FIN
J’veux pas voir de dossiers scripts ou build, ou env dans vos projets. J’veux pas devoir lancer 36 commandes, 10 services, et définir 14 variables pour bosser. J’veux pas que tout pète à chaque upgrade de mon OS ou parce que mon collègue Roger a modifié une variable d’environnement obscure au fin fond d’un script stocké dans un random repo git, ou parce que des scripts shell codés sur un coin de table et "enrichis" à chaque problème local rencontré par quelqu’un explosent une fois sur deux.
J’veux me concentrer sur mon application. Mon code. Sur la valeur que j’apporte à l’entreprise en bossant vite et bien, et en délivrant de la feature. Tout le reste, c’est du bruit. Et quand je bosse, je veux pas de bruit, enfin sauf Benighted dans mon casque bien sûr ! Gruik Gruik !
Il est 00:55, on verra demain pour les typos !
Add a comment
If you have a bug/issue with the commenting system, please send me an email (my email is in the "About" section).