Déjà eu des problèmes de "Module not found" ? Déjà eu besoin de mettre des "sys.path.append" partout ? Déjà eu des soucis de d'imports qui fonctionnent dans le code applicatif mais pas dans les tests ? Ou en local mais pas en CI / Prod ?
Reprenons les bases :
"Agile", un mot galvaudé, synonyme de "bullshit" ?
On pourrait être tenté de laisser ça
aux coaches, PO, PM, managers de projet, business analysts et autres animaux exotiques. En tant que dev, ce
qui nous concerne, c'est seulement le code, les bugs, Git et les tests ?
Nous voudrions vous montrer que
non. En retraçant l'histoire de notre discipline depuis 50 ans (génie logiciel, XP, ...), en présentant en
détail le manifeste Agile (ses valeurs, principes et auteurs), en examinant les dérives que cela a engendré
(Faux Agile, course à la certification, ...), et les réponses qui y ont été apportées (Craft et autres),
nous remettrons les devs au centre du débat. Nous parlerons aussi de notre ressenti personnels de
l'importance qu'ont l'Agile et le Craft dans notre profession, et de comment nous voyons leur évolution.
"Agile", an overused word, synonymous with "bullshit"?
One might be tempted to leave that
to coaches, Product Owners, Product Managers, Project Managers, Scrum Masters, Business Analysts, and other
exotic animals. As a developer, is our concern only the code, bugs, Git, and tests?
I'd like to show you
that it is not. By retracing the history of our discipline over the past 50 years (the birth of software
engineering, XP, ...), by presenting in detail the Agile manifesto (its values, principles, and authors), by
examining the drifts that it has engendered (Fake Agile, rush for certification, ...), and the responses
that have been provided (Craft and others), I will put developers back at the center of the debate. I will
also talk about my personal feelings about the importance of Agile and Craft in our profession, and how I
see their evolution.
Vous faites du Python et vous ne connaissez pas encore UV ? Ce talk est fait pour vous !
Vous ne faites principalement pas du Python mais ça vous arrive d'en croiser ? Ce talk est fait pour vous !
Vous trouvez que Python c'est naze, et vous ne voulez pas y toucher même avec un bâton ? Ce talk est fait pour vous !
En quelques mois, uv a révolutionné la façon d'utiliser Python, tout simplement. Et ça concerne tout le monde : Python est présent partout.
Venez découvrir ce que c'est, pour quoi faire, pourquoi, par qui, comment, vers quoi, vers où.
Promis, je serai impartial !
Si on vous largue au beau milieu d’un projet Craft, et que vous ne connaissez rien à ce milieu étranger
(et hostile ‽), venez d’abord récupérer votre Guide de Survie du Craft™.
Vous y trouverez 10 concepts essentiels pour survivre aujourd’hui dans cette jungle, ainsi que plein
d’autres pour vous assister dans vos prochaines explorations.
N’ayez plus peur des gros mots tels que TDD, SOLID, KISS, Clean, Pair Programming et bien d’autres
acronymes exotiques. Au contraire, vous obtiendrez une première compréhension du Craft, ses concepts et
pratiques, ainsi que plein d’idées à mettre en pratique par la suite.
Le Craft est pour moi un mouvement essentiel dans le milieu du développement, en ce qu’il est promoteur
d’apprentissage et d’entraide.
Signer un énorme client c'est cool. Ne pas avoir un système dimensionné pour l'encaisser c'est moins cool. Récit de mon expérience de test de charge avec l'outil k6.
Quelles (bonnes) questions se poser en amont ? Quel setup pour exécuter les tests de charge ? Comment on fait du k6 ? Qu'est-ce qui va mal se passer quand on va lancer les tests ?
Bref, j'ai plein de conseils à vous donner, une petite histoire sympa à vous raconter, de jolis graphiques et des mèmes à montrer.
Chaque métier a son jargon, chaque spécialité en rajoute. Cela rend la communication efficace, une fois qu'on maitrise tous ces termes. Ensemble, faisons une passe sur le vocabulaire lié au Craft, en toute simplicité, pour découvrir ces termes parfois inconnus, parfois déjà connus sous un autre nom. Petit florilège : code smell, refactoring, pair programming, design patterns, dojo et kata, TDD, ...
Des tests automatiques, on sait qu'il faut en faire. Mais trop souvent c'est une véritable corvée : c'est lent, pas fiable, compliqué à lancer, compliqué à maintenir, voire compliqué à écrire tout court. Pourquoi c'est si dur ? Et comment reprendre le contrôle ?
Il va falloir reprendre depuis le début : pourquoi on teste ? et on test quoi ? et on teste comment
?
Ensuite, il va falloir revoir un peu les bases du test : un brin de vocabulaire, et surtout de la
méthodologie (dépendances, interfaces, contrat, mock, simulateur, fixture, inversion, ...).
On fera un petit détour par l'architecture, parce que la testabilité est une propriété à prendre en
compte dès le design, ou bien il faudra jouer du scalpel ou du pied-de-biche par la suite pour les faire
rentrer.
Enfin, on passera à l'implémentation, et avec quelques bonnes pratiques et le bon outillage (framework
de test, TestContainers, CI, ...), ça se passera plutôt bien.
A travers des cas concrets tirés de nos expériences, suivez-nous sur le chemin pour quitter l'enfer des tests.
Il est assez facile de voir comment l'Agilité permet d'aller vite, mais la Qualité ne découle pas aussi
clairement de ses Valeurs ("Des logiciels opérationnels plus qu’une documentation exhaustive") et ses
Principes ("Un logiciel opérationnel est la principale mesure d’avancement").
On pensait en avoir fini avec le cycle en V, mais est-ce que garder le test comme une étape successive
du dev n'est pas perpétuer les mêmes causes d'un même échec ?
On voudrait vous présenter une vision différente du Test, et surtout de comment l'intégrer à nos
processus Agiles :
* l'intégrer très en amont (#ShiftLeftTesting), par exemple dès le raffinement du besoin
(#ExampleMapping et #BDD) ou lors de la phase de conception (#TestableDesign),
* anticiper les besoins techniques (#TestOps),
* éviter les défauts (#RightTheFirstTime et #Lean).
Venez découvrir (au-delà des #buzzwords) d'autres approches du test, en partant de cas réels, et en cherchant toujours comment, concrétement, assurer un bon niveau de qualité sur nos projets.
Benefits :
* améliorer sa vision du test pour mieux comprendre où ça coince
* mettre en place de nouvelles pratiques pour être plus efficace
* essayer de compenser une absence de culture Test ou QA dans une équipe
NB : "CFP" signifie "call for paper/presentation", et signifie qu'une conférence voudrait que des personnes fassent des propositions de papiers (articles scientifiques) ou conférences. On peut aussi parler de "call for speaker" (CFS) pour la même chose.
Pour être informé sur les conférences et leurs CFPs : le developers-agenda par Aurélie Vache, Sessionize "discover" ou Conference-Hall.
Mes conseils sur comment proposer un talk (et qu'il soit accepté) : sur mon GitHub Lenormju/talk-et-cfp
