Développer sur un gros monolith Rails ne se fait pas sans embûche. Chez Doctolib, nous tentons de toujours nous souvenir des gains apportés par le monolith et de contrecarrer autant que possible tous les inconvénients. Alors, à près de 200 développeurs, ça se passe comment ?
Yves Brissaud
Encore une conférence sur les micro-services ? c'est tellement pre-pandémie comme sujet. 🤷
Non, ce n'est pas une conf sur les micro-services. Enfin si... mais c'est pas pareil.
Ce dont on va parler c'est d'organisation, d'équipes, de communication, de topologie, de rôles, etc. Avec en exemple de nombreux changements qu'on a essayé, testé, implémenté chez Docker.
Alors peut-être qu'ensuite vous pourrez répondre à des questions du type "quelle taille doit faire un micro-service ?". Ou pas. Et d'ailleurs, tout ceci pourra s'appliquer même si vous ne faites pas de micro-services
Au cours de cet atelier interactif, nous explorerons le Clean Language et comment il peut être utilisé pour en savoir plus sur vous-même et sur les autres afin de célébrer nos différences au lieu de réagir avec tensions et non-dits.
Les questions Clean ont été affinées au fil de nombreuses années et sont conçues pour permettre au coach d'éviter d'ajouter ses propres présupposés ou jugements, et d'écouter de façon exquise. Enseigner ces questions aux équipes les invite à devenir curieux les uns des autres et à ne plus dépendre du ScrumMaster ou du Coach Agile pour communiquer.Vous pratiquez le mob programming ? Vous n'avez aucune idée de ce que c'est ? Venez découvrir le concept et expérimenter une approche par le jeu, qui vous questionnera profondément sur vos interactions avec vos équipiers, et changera la façon dont vous percevez votre façon de travailler.
Que vous développiez ou quotidien ou pas, vous aurez des choses à apprendre sur la dynamique de groupe et comment il est possible de co-créer du logiciel en tant que groupe.
Retour d’expérience sur 2 ans de dev sur du code legacy en utilisant le process « Test && Commit || Revert »
Nous y verrons les avantages et les inconvéniants mais aussi les trucs et astuces à connaitre si vous voulez essayer également.
Dans cet atelier, vous allez expérimenter et apprendre comment l'organisation d'une équipe influe sur son flux de travail, quelles sont les bonnes pratiques et les pièges à éviter.
Nous ferons des simulations d'organisation d'une équipe pour bien comprendre l'effet que cela a sur son flux total du travail.
Les sujets que nous aborderons :
Le TDD a changé ma vie. Pour de bon.
Après avoir commis presque toutes les erreurs possibles lors de ces 15 dernières années à faire du TDD, j’en suis arrivé à pratiquer une forme de TDD qui nous donne, à mes collègues et à moi-même, beaucoup de plaisir et d’efficacité. Une forme particulière de TDD que mon ex-complice Bruno BOUCARD et moi-même avons baptisé Outside-in Diamond 🔷 TDD.
C’est quelque chose qui nous permet d’écrire des tests à la fois orientés métier (ce qui n’est pas pour déplaire au passionné de DDD que je suis) mais aussi « Antifragile ». C’est de cela dont je vais vous parler aujourd’hui.
Le Domain Driven Design (DDD) a la particularité d’être compliqué à expliquer. Ce sera donc exactement le but de cette conférence.
On a tendance à penser que le DDD est complexe, mais c’est au final beaucoup de bon sens. C’est la quantité de chose couverte par le DDD qui le rend difficile à appréhender au début.
Avec des retours d’expériences sur des pratiques concrètes du quotidien, que vous pourrez appliquer dès demain, nous verrons comment rendre votre projet plus centré sur le domaine. Nous verrons également quels principes sont respectés grâce à ces pratiques, et en quoi cela peut être bénéfique pour une équipe, donc pour une entreprise.
Il arrive toujours un moment où, le logiciel est tellement gros et vieux qu’il devient inmaintenable. Impossible de mettre à jour la stack technique sans tout casser, les nouvelles fonctionnalités deviennent de plus en plus longue à implémenter et la dette technique étant tellement lourde que le refactoring devient exorbitant.
Et si on vous disait que tout ça était plus un problème de pratique qu’un problème de vieillesse du logiciel ?
Venez découvrir par ce retour d’expérience, comment l’Architecture Hexagonale peut tacler la complexité logicielle en vous permettant d’être évolutif et pérenne tout en vous aidant à mieux gérer votre dette technique.
Quel est le point commun entre une base de code entre les mains d'une équipe de dév, une équipe de dév au sein d'une entreprise, un produit vis-à-vis de ses utilisateurs, une entreprise vis-à-vis de son marché ?
Si vous avez répondu du tac au tac "ce sont des systèmes complexes soumis à des forces nombreuses avec des effets et des temporalités souvent difficiles à analyser", vous devriez apprécier les défis proposés lors de cet atelier. Si vous n'avez pas fait le lien immédiatement, vous pourriez y faire une découverte utile voire salutaire.
Le propos de cet atelier est d'explorer ce qui rend les systèmes si difficiles à gouverner, qu'il s'agisse de lignes de code ou de populations exposées à une pandémie, mais aussi de montrer en quoi certaines "lois" se retrouvent indépendamment des domaines et nous fournissent des outils et des réflexes à cultiver.
Matériel nécessaire: les participants doivent avoir un laptop pour 3.
Que faites vous si votre entrainement devient trop facile? Ajoutez des poids! Peut-on faire cela avec des code katas?
Le design incrémental consiste à arrêter de penser au design comme gravé dans le marbre, mais comme une infinité de petits pas. Maitriser les petit pas est un pré-requis pour le design incrémental. Mais comment enseigner les petits pas à vos collègues expérimentés qui se "débrouillent" pour résoudre un kata en une poignée de grands pas?
TCR (test && commit || revert) est une machine d'entrainement au petits pas à ajouter à vos katas! En plus d'enseigner les petits pas, cet outil:
La charge mentale est un facteur humain peu ou pas assez considéré dans l'organisation des projets logiciels.
Nous verrons en quoi celle-ci est pourtant un élément clé de la performance et du bien-être des équipes.
Quel est le lien entre charge mental et structuration des équipes ?
En quoi celle-ci peut avoir un impact sur la performance ?
Nous l'explorerons au travers de la découverte de grands noms comme Felienne Hermans, J. Sweller, Yerkes & Dodson, et de références comme le livre Teams Topologies.
Vous avez envie de développer des IHM de bonne qualité ? Utilisables ? Intuitives ? Venez découvrir quelques recommandations basiques pour améliorer l'ergonomie de ce que vous produisez.
Les administrateurs systèmes sont encore traditionnellement les personnes gérant la totalité des applications de l'entreprise en production. Pourtant, et depuis maintenant plusieurs années, une nouvelle tendance apparaît: laisser les développeurs gérer leurs applications en production.
J'expliquerai dans ce talk l'intérêt de cette approche et du rôle des administrateurs systèmes et SRE dans la construction de l'abstraction permettant d'atteindre cet objectif, le but n'étant en effet pas de supprimer les administrateurs systèmes mais de travailler en partenariat avec eux.
Je donnerai également des retours d'expérience sur la mise en place de cette approche et des difficultés rencontrées, comme par exemple sur la création d'astreintes dans les équipes de développement
La programmation fonctionnelle est de plus en plus mise en avant, mais pourquoi? Qu’y a-t-il de différent avec la POO?
Nous vous proposons de partir d’un kata bien connu pour illustrer les différences (implémentations en C# existantes) et dédiaboliser la soi-disant complexité de la programmation fonctionnelle.
Les différences de notation forment le principal obstacle, une fois passée, la programmation fonctionnelle n’est pas plus compliquée. Nous aborderons le langage F# pas à pas en illustrant notamment le système de type (dit de “types algébriques”) pour avoir un design piloté par les types (TypeDD).
VidéoTout travail que l'on termine est vérifié au moins manuellement en local dans son coin, mais cette pratique ne résiste pas dans le temps. Voyons pourquoi et comment lutter contre l'apparition des régressions qui fragilisent notre système, ralentissent notre productivité et mettent à mal la maintenabilité de nos logiciels.
Depuis des années, j'ai constaté que je n'écris plus de classes abstraites dans mon code et je me suis donc posé la question "Pourquoi je n'ai plus de classes abstraites dans mon code ?".
En creusant la question, je me rends compte que c'est depuis que j'ai commencé à appliquer le TDD ( "Test-Driven Development" ou développement dirigé par les tests). Mais quel est le rapport entre les deux ?
C'est ce que je vais tenter d'expliquer via ce talk.
VidéoVous avez envie de gagner en efficacité dans votre travail de tous les jours ?
Vous savez qu'il existe des raccourcis claviers mais vous n'arrivez jamais à les retenir ?
Venez vous entrainer ensemble et découvrir de nouvelles astuces pour programmer plus rapidement.
Langages proposés : .net, java, kotlin, typescript.
Les exercices sont guidés pour IntelIj et Visual Studio Resharper, mais rien ne vous empêche de participer avec votre IDE préféré.
Pré-requis :
Tout le monde s’accorde pour dire que le TDD c’est bien, mais peu de personnes le pratiquent au quotidien.
Cette pratique semble bien sympa quand on voit une démo sur un petit algo, mais finalement le code de nos projets ne ressemble pas trop à ça. Notre quotidien est plutôt rempli de contrôleurs, bases de données, classes de service et divers dépendances difficiles à tester.
Nous vous proposons de montrer comment nous travaillons avec des tests en TDD pour construire une petite application REST connectée avec une base de données.
Nous discuterons aussi de ce que nous considérons être un test utile et comment cela change avec l’âge du projet.
On retient principalement du TDD l'écriture des tests avant le code. On entend aussi dire qu'il est plus efficace. Mais par rapport à quoi ?
Dans un épisode précédent, "Artisanat logiciel, un regard zététique", on avait commencé à confronter nos croyances concernant les bonnes pratiques avec un état de l'art de la recherche scientifique. A cette occasion, on avait fait la connaissance d'ITL (Iterative Test Last) qui semble présenter des résultats similaires.
Comment est-il possible d'être aussi efficace que le TDD sans changer sa caractéristique principale ? Et si le secret de l'efficacité était ailleurs ?
Dans cette conférence on va:
Plutôt qu'un débat de spécialistes sur un sujet pointu, l'idée est plutôt d'utiliser ce cas concret pour entraîner notre vigilance intellectuelle et notre esprit critique. Et en dessins s'il vous plaît !
On dit que pour être un·e professionel·le du code il faut respecter le Single Responsibility Principle. Comme d’habitude, les exemples et les tutoriels sont simples, et la vie réelle est compliquée. Avec cette session nous montrerons en live coding, comment mettre en œuvre ce principe de responsabilité unique et les possibilités qu’il ouvre au quotidien.
Cette journée est une non-conférence. Cela signifie que le programme de la journée est défini sur place, par les participantes et participants.
Cette année, nous avons travaillé autour de la question : Quels sont les sujets, les idées, les questions que je veux explorer pour produire des logiciels toujours meilleurs?
En début de journée, chaque volontaire propose une ou plusieurs sessions qu'il ou elle aimerait animer (présentation, coding dojo, atelier, échanges sur un sujet donné, ...), où à laquelle il ou elle souhaiterait participer. Le planning de la journée est établi à partir de ces propositions.
L’ensemble des rapports des sessions est affiché dans l’espace du “Grand Journal” pour que tou.te.s les participant.e.s puissent en prendre connaissance.
Retrouvez l'ensemble des rapports produits lors de la journée ici
Un grand merci à nos sponsors qui nous soutiennent et sans qui AlpesCraft ne serait pas possible
Maître
Historique
Apprenti
Merci à nos partenaires de nous faire confiance
