Llewellyn Falco

The single worst architectural anti-pattern is also the one I see the most often. It locks you into an architecture. Makes your choices permanent and inhibits being able to respond when you need to scale.

We are going to look at multiple examples of this anti-pattern. Not only focusing on how to avoid it in the first place, but also how to restructure code once you have detected it in your current system.

Let’s get back to basics.

One of the microskills often used in TDD is Consume First Architecture, which simply means using the fields and methods before they exist. Sounds easy? Well yes and no. Even simple lines of code can have HUGE implications on your architecture. The real skill in consume first is to be able to see, question and respond to those implications on sight.

In this lab, we are going to geek out over a single line of code. We will take it and turn it into 40-50 variations and explore how each variation impacts the resulting design.

In this guided demo, we are going to look at 3 different techniques that are remarkably powerful in combination to cut through legacy code without having to go through the bother of reading or understanding it.

The techniques are:

Combination Testing: to get 100% test coverage quickly

Code Coverage as guidance: to help us make decisions about inputs and deletion

Provable Refactorings: to help us change code without having to worry about it.

In combination, these 3 techniques can quickly make impossible tasks trivial.

Will will be doing this on the Gilded Rose Kata, https://github.com/emilybache/GildedRose-Refactoring-Kata

It is extra beneficial if you try it out yourself first so you can see how your implementation would differ.

“In order to make delicious food…. you need to develop a palate capable of discerning good and bad. Without good taste,
you can't make good food.” - Jiro Ono (World’s Best Sushi Chef)

Many of us are stuck with messy code. We know it’s not great but it works and what can we do? Where and how do you start?

We are going to use some cutting edge training to train your pattern recognition section of your brain to instantly recognize common, reoccurring anti-pattern (smells) in your code.

Then we will learn very specific techniques to start improving on these specific smells.

Once you are trained to see these anti-patterns you’ll recognize them everywhere. Now that you are equipped to handle them your code will start to transform into something beautiful and easy to work with.

Red - Green - (refactor)

We all know that refactoring is suppose to be the step that let’s us tease apart the logic of our code. ‘Fake it till you make it’ allows for us to evolve an emergent solution to complex problems. Yet this is usually glossed over when showing Test Driven Development.

But not in this session. Here we are going to focus completely on Fake it till you make it. Taking complex katas and reducing them to

1 Red - 1 Green - 40 Refactors.

Like everyone else, you have a large product that is hard to work with. We're going to change that in 75 minutes. Together we will save some gnarly legacy code (one thousand-line function). We will start with something hard to read, untested, and possibly buggy. We will finish with code that is stupidly easy to modify. You'll learn 6 trivial techniques that you can apply over and over to fix 95% of the messiest code you have. You can take home this exercise to help the rest of your team learn these techniques. You'll also learn how your team can teach itself a bunch more techniques to handle the other 5%.

We are going to save some legacy code. In 90 minutes. While adding features. We will mob program; you will save this legacy code. We won't introduce any bugs along the way. We will spend the time that you would normally use reading code to instead make it readable. You can apply these techniques and reduce the cost of coding within 48 hours of getting home.
We have done this exercise with dozens of teams. They code differently now. Changing existing code is actually safer and cheaper than writing new code. Their designs get a little better each day. This session will improve your code and show you what skills to learn to gain further improvements.

Learning Outcomes:
Know the 6 refactorings required for reading code by refactoring it.
Differentiate between refactoring and micro-rewrites (code editing), and choose each where appropriate.
Have fluency in the key refactorings with one tool set and know how to spread that fluency to other tools and to broaden the skills within that tool set.
Able to start successfully saving legacy code without making major investments, even with no tests.
See an obvious path for continuing to learn design and refactoring skills - know where and how to get feedback and can create own curriculum for next 1.5-3 years of improvements.

Over the course of my life I have amassed a great quantity of 1-3 minute talks. Tonight we are going to Randomly pick from that list and see where the adventure takes us!

Talks:
Test Driven Math
10 X
A swimming pool isn’t just a bigger bathtub
Bdd vs TDD
Arlo’s Git Notation
The Curse of knowledge
Do NOT use the greater than sign in programming
DocDoD
Sparrows
Leveling up
On being the best
Quantum Computing
Theory Based thread testing
Better Lunches
Decision trees
Sustainable Pace
Standing alone
Better Interviews
Duplication and Cohesion
Generic Type Information at Runtime in Java
Make the easy change

If you think pairing programming ( 2 people on 1 computer ) is crazy, hold onto your hats; it’s time for Mob Programming.

Mob Programming: All the brilliant people working on the same thing, at the same time, in the same place, and on the same computer.

We are going to take a look at a new way of working, what it looks like, and why it can work. More importantly, we’ll have a (very) short session of actual mobbing, so you can see for yourself and come to your own conclusions.