TIM AND CHRIS'S AMAZING LRUG TALK.
-OR-
THE RIVER WILD: NAVIGATING YOURSELF PAST THE WATERFALL
Idea that legacy code isn't just 'old' or written by someone else. you can be writing legacy code now!
I was thinking we could structure the talk like this lots of little units consisting of
- A problem we faced
- How we identified it
- How introducing an 'agiley' technique helped us and how we did it
- How we persuaded non-technical management and stakeholders that it was a good idea
Then a summing up showing how in general looking at specific problems like this made the whole project better.
A few things:
From DDD - importance of universal language, iterative modelling.
Test smells - big setup and teardown, not respecting separation of concerns MVC gives natural boundaries for mocking / stubbing. Test units and enforce contracts. - Design by Contract and Invariants are useful here. 'Working with legacy code' has some good stuff on invariants, mocking / stubbing, and breaking dependencies in testing. Minimise hand-written cucumber steps, should be browser based - testing interactionss, as you would in a sprint review - acceptance testing
Code smells - State machines vs inheritance vs composition. Smells: denormalisation of states, big logic in callbacks, esp instantiation of dependant objects on_create
Abstractions that don't make sense - universal language and code coverage provides a clue here. Eg fills.
Persuading managers:
Requirements gathering and story writing - If regression has ever been a problem they will LOVE this. Encourage them to talk in terms of business requirements, not interactions. Avoid the language of your system if it's not plain old domain language. Helps you see what is a requirement and what isn't. Helps them see that too.
Morning standups are an easy win - everyone will go for them Pairing also has decent arguments for it - makes sure everyone understands important areas of the codebase (if you're on a waterfall project chances are this has been a problem in the past) Can subteley introduce sprints by saying 'we've got some big stories here, choose the most important 3 and we'll regroup on friday and see how we got on' Avoid using 'Agile' language - people are more resistant to change when it has a name (from succeeding with agile book)
Realising you have a problem:
Another thing to focus on is realising that there is a problem. Rather than trying to get the flawed design to work, going back to first principles and rethinking what the problem is that we're trying to solve. Too often we focus on 'polishing a turd' when there's a far simpler approach right in front of us.
Some good things to do up front:
redo your features. This was quick once we'd got the environment set up, and allows us to refactor everything else with confidence. Also good way of measuring the requirements we've defined through story writing
Good features lead to good code practice
Ideally your features should be completely implementation agnostic - however some pragmatically designed features can lead to best practice coding design decisions.
- For example, having a feature that looks like:
Then I should see the task: "Task 1" is complete
And use the 'is complete' to look for a specific css class called 'complete'.
- Ensuring that fields have labels e.g.
When I fill in "Name" with "Brett McKenzie"
Having labels is a good thing for seo, screen readers etc, by writing the feature making an assumption that the label is there is healthy. If you don't want the label displayed then a dose of css easily hides it away.
*we found our models were less tightly coupled than we expected - our specs were however, due to massive setup and teardown, and not using blueprint properly
- Your code is transient, and probably really bad Deleting code is awesome. Your code sucks. It's nothing personal if your code is rubbish, just identify how it's bad and fix it