Have you ever found yourself or a colleague needing to implement a new feature, but unlike previous feature requests, this one gets all awkward when you try to work it into your existing codebase? When this happens, you know you need to refactor, but it's not clear the best way to do so -- or how to refactor without losing several days to it.
Or maybe a team member is learning a new technique and when you both looked at your work code you realized it's hard to see how the little practice classes correspond to a real world monolith sitting on multiple frameworks. How do you take those lessons into your legacy codebase?
This workship is suited for longtime or newer programmers
Modern development is about adapting to change. All codebases make assumptions -- some blatant, some subtle. No matter how cleanly your team works, evolving business needs will eventually challenge every one of those assumptions. A feature which looks simple on the surface will clash with assumptions you didn't even realize you were making. When that happens, engineers sometimes assume that they have to choose between three days of refactoring or piling on the technical debt. Both options lead to bad results.
The workshop explodes this false binary. Participants will learn incremental, test-validated refactoring techniques that carry through naturally into the real world and allow them to refactor more efficiently and effectively. Attendees learn how to:
- Save time by closing off false trails to bad refactors sooner
- Break free from programming patterns that are no longer serving you
- Apply refactoring theory to a real world environment
Along the way, we'll explore some of the uncomfortable moments in refactoring, like when you get that horrible sinking feeling because you can't see anything better than writing repetitive code). Attendees will work together with faciliators to tackle adding new features to realistically bad legacy code -- the kind that’s difficult to extend, but readable. Most of the workshop is spent in a faciltated mobbing session. Your team won't only develop a common language for approaching refactoring problems -- they’ll learn to apply this common language to real-world Rails codebases. Attendees will learn about and practice a few programming tools they can take with them:
- TDD's Red/Green/Refactor cycle
- Single-line changes
- Mobbing for alignment
"After learning about one-line refactoring in the refactoring workshop, I tried it at work where we're going through a massive scary refactoring. This technique helped me have more confidence and go through faster than we would have otherwise." ~ Jeffrey Baird
“Jennifer was a great facilitator -- I really felt like I could participate, but also like I could defer to others when I didn’t feel confident. She managed to draw out an intentional, thoughtful discussion of engineering principles.” ~ Maeve Andrews
"I learned a ton from Betsy and Jennifer at their refactoring workshop. I'd encourage anyone to take it." ~ Valerie Woolard Srinivasan
"Really enjoyed this workshop when I participated during RailsConf. Learned some new techniques for doing TDD better... and that sometimes the path to cleaner code involves things getting uglier before they get prettier again." ~ Fiona Voss
"It helped me get a much stronger intuition about tensions in refactoring work, and be able to know when to put off code-structure decisions (man that's uncomfortable) until I can make more assured and cohesive improvements." ~ Roman Kofman
After this workshop, your team will be better prepared to change your codebase to be easier to work with. They'll have the tools to tackle a refactor in a way that won't leave broken code blobs when the schedule gets tight.