Llewellyn Falco is an independent agile coach. He discovered strong-style pair programming. He is creator of the open source testing tool ApprovalTests( www.approvaltests.com ). He spends most of his time programming in Java and C# specializing in improving legacy code.He is the co-founder of TeachingKidsProgramming.org & co-author of Mob Programming Guidebook
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!
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 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.
“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?
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.
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.
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.