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.
Abstract :
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 teste quoi ? Et on teste comment
?
Ensuite, il est nécessaire de 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.
Titre alternatif : Faisons rimer Agilité, Qualité et Rapidité !
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
Si vous avez déjà essayé de mocker, vous avez sûrement eu du mal à bien les appliquer.
Si vous en avez plein vos tests, vous avez sûrement remarqué qu'ils sont faillibles et fragiles.
Mais ils peuvent aussi être très puissants, ce qui les rend très utiles pour le test.
Afin de les utiliser efficacement, il faut d'abord **comprendre vraiment** comment ils fonctionnent,
leur interaction avec le système d'import, le modèle objet de Python, et l'architecture des programmes.
En particulier, il faudra apprendre à discerner les "références" que Python utilise partout (des sortes
de "pointeurs"), et les concepts d'immutabilité et de passage-par-copie/référence.
Avec tous ces savoirs, vous pourrez prédire le comportement des mocks, et réussir à les utiliser
sereinement.
Vous confronterez alors cette compréhension à des exercices concrets de comment appliquer des mocks.
Enfin, vous aurez des conseils d'outils à utiliser pour tirer un maximum de vos mocks, mais surtout de
quand ne pas les utiliser.
À l'ère de l'IA, les devs expérimentés qui ont l'habitude de piloter une équipe sautent facilement dans le train de l'IA, utilisant un ou plusieurs agents dernier cri pour se transformer en "équipe à soi tout seul" capable d'accélérer spectaculairement leur projet. De l'autre côté, les développeurs débutants, pas formés à l'usage de l'IA, se retrouvent critiqués pour accepter trop facilement le code approximatif généré par leur modèle et saturer le pipeline de revue de code. Alors, comment fait-on maintenant pour passer du débutant à l'expert ?
Après avoir rappelé que l'IA ne se diffuse pas si vite que ça chez les industriels, que nous avons tous
démarré en faisant des erreurs grossières, et que la nouvelle génération plongée dans l'IA dès le
premier commit est mieux armée que l'ancienne pour dompter ce nouveau paradigme, nous présenterons la
nouvelle orientation prise par le métier de développeur. Moins de lignes de code délicatement ciselées,
et davantage de revue de code généré, le développeur doit migrer vers un rôle de plus haut niveau,
plus exigeant, en insistant sur les fondamentaux de l’ingénierie : définir le problème, proposer des
solutions, les challenger, choisir, implémenter, tester, recommencer, le tout assisté par l'IA à toutes
les étapes.
En parallèle, il devient encore plus important d'insister sur la vision globale des technos logicielles
afin de naviguer dans un écosystème qui accélère encore, et sur la communication avec à la fois le
commanditaire du code et ses utilisateurs, essentielle pour atteindre le but du projet.
Enfin, certaines compétences perdent de l'importance, comme la connaissance exhaustive d'un langage ou
d'une techno, et la spécialisation perd de l'importance face à la capacité de s'adapter et d'aller
vite.
Les experts et enseignants doivent donc insister davantage sur le processus, et moins sur le code. En
parallèle, les débutants doivent apprendre à tester et valider chaque ligne, pas seulement en faisant
générer un test à l'IA, mais en s'assurant que le test garanti effectivement ce qui est attendu dans la
spec. Et tout le monde se recentrer sur notre coeur de métier : développeurs de solutions, pas simples
codeurs.
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
