Eating Legacy with 3P

When you write tests or refactor at the end of a story, or worse in a separate story, who gets the benefits? And when?

It's the next person who touches the code ... sometime in the future ... if we're lucky. Given that the tests remain relevant. And given that the refactoring actually helps with the new functionality, that we don't know yet ... 🤔

That means our efforts in refactoring and tests are primarily for other people, sometime in the future and of uncertain value to them. Is it surprising if we don't do much of it and let the code rot?

*An alternative, that maximises the ROI of the tests and the refactoring, would be the Protect-Prepare-Produce* method 🧐.

# Protect
Write quick and dirty(!) tests to protect refactoring in next step. Beware this can hurt some sensitive viewers.

# Prepare
Refactor in depth to make the new functionality easier. Also make the code testable and improve the tests written in the previous step.

# Produce
Code the new functionality in TDD. Should be a piece of cake given the Prepare phase.

Being the primary beneficiaries of the testing and refactoring we do ourselves means more happiness. With a much better ROI on testing and refactoring, we're likely to a lot more of it.

Let's make this clear with a few examples. Not the least what I mean by QUICK and DIRTY tests

Découpe mon monolithe

Vous vous dites qu'il faut arrêter de faire du logiciel couplé, arrêter de faire grossir le monolithe. Peut-être même commencer à faire des micro-services indépendants! Sauf que … ces services ne seront peut-être pas si indépendants que ça :(. Peut-être qu'ils se parleront en synchrone, alors quand l'un est HS, les autres le sont aussi. Peut-être que ce sont des minuscules petits services qui dépendent d'un énorme service BDD :S. Peut-être que tout le monde se partage la même base (au secours). Ce workshop est conçu pour ceux qui se posent ces questions.

Votre mission lors de cet atelier est de découper un morceau d'un monolithe existant. Embarquez pour un voyage architectural vers les synchronising services et un monde de possibilités s'ouvrira. Vous visiterez le Bubble Context, Bounded Context, Open Host Service et Domain Events…

Vous n'avez pas besoin d'ordinateur ou de connaissance d'un langage particulier. Uniquement votre cerveau est requis :)

Split my monolith!

You believe that uncoupled software is that way to go? You think that that big monolith should get smaller. Perhaps even cut into independent services? Except that ... these services don't seem so independent after all :( Maybe they'll talk synchronously, so when one is down, the others are unable to respond. Maybe the only apparent possibility is tiny services, all calling one central backend, with a huge database :S Maybe all services would share the same database (help!!) If you ask yourself how your monolith could sensibly be cut into pieces, then this workshop might provide you with some tools and inspiration.

Your mission during this workshop is to cut a piece of an existing monolith, including its database. Come along on an architectural journey to synchronizing services and a world of possibilities will open. You'll become familiar with a few tools to separate what seems unseparable. You'll identify Bounded Contexts using tools like time-lime, user actions, data clumps and command and query separation. From that you'll model a Bubble Context using, Anti-Corruption Layers, Open Host Service and Domain Events ...

Le non unitaire du TDD

Le TDD s'associe souvent à des tests unitaires. Mais cela n'est pas toute la vérité et surtout cela a tendance à guider les gens dans une impasse.

Au delà des exemples basiques du TDD, regardons comment on s'y prend sur un vrai projet.

Difficile de développer une story en TDD? Les tests sont écrits après le code? Le code qui s'intègre avec d'autres systèmes est peu testé ou testé avec des mocks? Il y a beaucoup de tests à modifier pour refactorer du code? Voici quelques symptômes qui peuvent venir du même mal - une conception trop "unitaire" des tests et du TDD.

Certes, nous voulons des tests unitaires pour le besoin de reproductibilité, rapidité, maintenabilité etc. Mais ceci n'est ce qui nous importe lorsqu'on développe une nouvelle fonctionnalité où nous avons plutôt besoin de découvrir la réalité des choses, les problèmes d'intégration etc.

Comment allier les deux besoins? Que peut-on se permettre dans la phase de construction? Que fait-on avec les tests peu maintenables dans la CI? Les mocks, sont ils bien ou pas? Quels tests pour l'intégration avec "l'externe"? Puis-je faire avec mon projet "legacy"? Les réponses vous attendent dans cette session.

De Legacy au TDD

C'est quoi l'obstacle principal à travailler avec les tests ou en TDD. C'est que le code existant n'a pas été concu pour! Voyons à travers un exemple comment on reprend le code, le prépare au travail en TDD à l'aide des tests :) et du refactoring préparatoire afin que cela devienne un jeu d'enfant d'ajouter la nouvelle fonctionnalité en TDD (ou presque :D)

Nous verrons comment le besoin fonctionnel nous pousse à rendre le code plus modulaire, ce qui in fine le rend testable plus unitairement. Parfois on dit que le refactoring coûte, dans ce cas c'est le refactoring et le TDD qui nous fait gagner du temps.

Filmed at Agile Pays Basque
https://www.youtube.com/watch?v=CG5ruSfRg88

BugsZero Kata

(This is a hands-on lab with limited capacity. You should receive an invitation to sign up for your favourite session at latest one week before the conference. Capacity of this session = 28)

Bugs are optional, they get their way into our code much thanks the design choices we do or quite often fail to do.

You'll practice reading code, looking for parts where it is likely that a developer would create a bug if he extended the code.

Whenever you've found such a weakness in the design your challenge is to strengthen the design in order to make that kind of bug very unlikely, or even impossible!

You'll practice the procedure of
* Identify a weakness in the design
* State what the potential bug is before explaining your solution. This is important, simply saying another solution is better avoids thinking of why it is actually better.
* Explain or refactor the code to show the new design.

Prerequisites:
You can buy some time by configuring the codebase https://github.com/martinsson/BugsZero-Kata

Bug free, by design

Get rid of whole families of bugs for good with 21 tricks to reduce the space available for bugs.

Bugs are not a fatality, they appear whenever the design allows for it. Learn how to fix the root-causes and how to give an intrinsic quality to your code.

You'll look at static and dynamic typing in a different way. Learn about NoPrimitives, coupling & cohesion, if-less. We'll talk about the feedback-funnel and how it all scales from micro design to micro-services and to macro-design.

Loads of concrete examples and some live coding

Pas d'agilité sans livraison continue

Il est démontré que la livraison continue apporte une valorisation sur le marché 2 fois supérieure et cela apporte en même temps une bien meilleure satisfaction des employés. La livraison continue est aussi là où le business, l'agilité et l'excellence technique se retrouvent alliés dans le même sens.

Des données sur des centaines d’entreprises et des dizaines de milliers de personnes à travers le monde ont démontré que les entreprises les plus performantes sont celles qui déploient plusieurs fois par jour.

Est-ce vraiment le cas ? Comment se fait-il que ce soit si important ? Est-ce que cela demande beaucoup de budget et d’effort ? Le coût d’entrée est-il rédhibitoire ?

Plutôt que de pousser des bonnes pratiques dans la douleur, on vous propose d’impliquer la direction de l’entreprise dans un changement avec un but business qui aura besoin d’agilité et d’excellence technique pour réussir.

On expliquera en quoi la livraison continue donne un avantage compétitif hors norme, et vous repartirez avec quelques clefs pour démarrer dès demain votre transformation et livrer vos clients plus souvent.