Practical Refactoring - How to clean code in many small steps

For more follow

Woody Zuill
Llewellyn Falco

Also checking out our conferences:
Mob Programming Conference -

[coJetty]

Loved the fact, that you overlayed audience questions. Thanks for the additional production quality. Realy new to me was refactoring the code even before understanding it. Great advice. Overall insanely helpful.

[briza_md]

I just wanted to let you know how much I appreciate this video.
Thanks for teaching us viewers!

[eNSWE]

coming back to this video from time to time, taking it all in and thinking of ways to incorporate it into our workflow.

but also because it's SO damn satisfying to see such an ugly horrible mess get transformed into something expressive, coherent and maintainable. it's a work of art!

[chriskoontz]

I've been in technology for over 30 years. This lecture was extremely well done.

[sapito]

best two hours invested ever
best ending ever

[shubhamjain]

9:28 Leave things BETTER than you found them
10:45 Be ready to commit your code within 2 minutes and leave
12:06 Arm yourself (with tools)
14:12 What makes code hard to work with
17:21 Remove the 3 C's:
42:53 Removing complexity
1:17:57 Removing cleverness
1:49:11 Next Moves

[NitsanAvni]

Beautiful! So much goodness. And so nice to see you both collaborating :)

[andyrobertson]

Excellent stuff. Thanks for an extremely interesting and useful video.

[nagone]

Fantastic video. Lot of learning and clean code is definitely a great book to read.

[MurtagBY]

That is great content. Thank you for sharing and also editing the video (question overlays)

[rockYhre]

This was very useful, thanks for sharing.

[misspham]

Amazing talks guys! We all know what good practice is, but it's sometimes very hard to move in small steps to get from bad code to good :) This helps a lot

[ericcartmansh]

Fantastic video. Lot of learning and clean code is definitely a great book to read. There is a new video series by uncle bob called clean coders on his site. Really worth checking out where he breaks down some of the stuff talked about in this video a lot more

[HenrikForsberg]

Really good video! The sound was a bit loud, but still the best 2 hours today :)

[mindprism]

That was amazing. I guess in 10 years the tools will just comb out your code automatically, you just sit there and suggest the names as the process churns on.

[SoeaOu]

Remember that this was recorded in 2012.
Audio suck, the clutter on the screen is immense, committing through the "explorer" via a mercurial UI interface gives a peek how horrible it was back then.
First hour is goofy and low value but then it picks up the pace and the good stuff comes flowing.
Still worth watching the whole thing. Put this on x1.25 speed and enjoy the ride.

[Truthiness]

Great talk, I'm putting the crux of all this on a note card for future reference for when I refactor my most recent project again. Really refreshing to hear a talk about refactoring without it just being the 1, 578, 305 time nerds have sat around and had a circle jerk about the GoF's [at times helpful and at times growth-stunting C++-based] design patters.

One downside to this talk though is after that first guy butted in, this became open-mic night (not [fully] these guys' fault). Framework design is like quantum physics: if you think you filly grasp it, you're the least educated on the subject in the room. If the few in there that couldn't stop in the "knowledge" from their "1337 proggy skillz" (see: they read a bit from the GoF and now they think they know good design...), this talk would have gotten further and all of their annoying input would have been dismissed all the same (and, fuck, if they'd shut up and listen they might have learned something, but then again that's how they got their stupid opinions they had to begin with...). Anyhoo...

[toodough]

(Too Long Didn't Read: refactoring takes time, so how do I easily demonstrate benefits to others?; what about very complex code that is very difficult to refactor, what to do in that situation?)

This was absolutely brilliant and I'll share it to my colleagues. A couple of questions which I would highly appreciated a reply on:

(background: I work in a very agile start-up, things change a lot, BUT our product is big - a sort of a game engine - and robustness of the core classes is crucial in my opinion)

1) The main issue I run into when I suggest stuff like this at work is "it takes too long" or "I don't see the benefits" and even though I understand the benefits and long-term you always win with good code, I find it hard to show this to people. Do you have some sort of a document/presentation that clearly outlines how important good code and refactoring is ? Thanks!

2) In this video, the class presented with is quite trivial to refactor IMHO. However, I've encountered situations with code so bad and so complex that changing any line breaks absolutely everything. So, in situations like this is it easier to just start from scratch or how do you plan/assess the next steps in refactoring such a monster? Thanks

[toddflanders]

Bravo! I'm new to approval tests. Is there a point in a legacy rescue where you decide to replace approval tests with hand-written tests to act as an executable specification? Approval tests look like they should be temporary scaffolding to clean code safely, but now I'm questioning if you ever really need to have TDD-quality tests in a legacy rescue...

[scharlesworth]

Hey wait it should be called 2 hours to better code.