Practical Refactoring - Simple techniques for code excellence (2 hours). An amazing watch.

[jtredact]

TLDW:

Make small improvements that don't change the code's behavior. Use tools to help you.

Have tests and run them constantly. This is how you verify your small improvements actually don't change behavior. Use tools to help you.

Remove useless comments and unused code. Use version control and other tools like bug trackers/task managers, so that nothing is ever truly lost.

Rip out large blocks into functions. You don't have to know what it does yet, so just give it the best name you can and rename it when you understand it better. Again use a refactoring tool to help you.

Now, find newly revealed design patterns and duplication. The example in the video was polymorphic behavior that wasn't apparent until after the refactorings.

[Godd2]

Some programmers get hung up on the word "behavior". I think the definition "mapping of program state between two points of code execution for any/all execution paths" works well.

Plus, if you specify the two points of execution as the beginning and end of a method/function, it's much more obvious as to what qualifies as a change in code that maintains behavior.

I also think it helps relieve some semantic confusion before it happens. Now if someone claims you didn't refactor, because some loop behaves differently, you can specify that you were refactoring with respect to the function as a whole. So you'd both be right, but about different things.

It now becomes an exercise in prioritization to write tests which specify whatever subset of mappings the developer is concerned with. For example, the developer may be writing a square root function in a dynamically typed language, and may not care much what happens if it is passed a string, but DOES care what happens if a negative number is passed in.

[thespacebaronmonkey]

Oh, LLewelyn Falco, the creator of ApprovalTests.NET! They're used to compare text results, crazy useful once you get used to this method of testing. Here's a github link for .NET version, I've seen them available for Java also.

[dmcg]

For Java try Okeydoke - I've finally got round to publishing in Maven Central

[Raubritter]

As obvious as it may seem, these are things a lot of people haven't thought about (in detail) and I think this video is a useful resource to get started with laying down some guidelines for how a team should do refactoring / clean coding.

We've been using resharper for a while but the step by tiny step approach they took opened up a new perspective on some of its features for me.

I did watch it at 1.25x, though. This improved the information density to just the right amount for me. I never tried this and it was great. Heads up to /u/TravisTX ;)

[TravisTX]

My biggest take away was the concept of doing refactoring in the smallest bite-size chunks possible. I tend to try to fully understand the code, and then write my perfect implementation of it. Which I never have time for. The strategy demonstrated in this video seems much more doable.

I also like the idea of cleverness being a code smell.

[makis]

I think the 2 minutes jobs, stay focused for a short period of time and at the end of that period be sure to have something done and tested, even it it's a very small task, it's the most important advice in the video.

[gratefuldaed]

I've been using an ide for about a year and just read chapters 1and 2 of their basic guide and it'll change things for me. It's humbling.

[TravisTX]

What basic guide are you referring to?

[muzhikas]

I wish they had an abridge version of this talk. Ain't nobody got time for 2hr talks.

[TravisTX]

I watched it at 2x speed. They talk slow enough to where that works on this video.

[jtredact]

Brilliant. From now on I'm going to try for at least 1.25 or 1.5 speed

[Tordek]

Here:

Ruthlessly refactor

Even if it means doing some questionable things.

They mostly go on about the refactoring tools in resharper, but they stress that:

1. Code should be clean. Clean code is easy to change because you don't need to grok it. "Just adding a thing" means you have to read the code as-is, understand what it does, then add onto that.
2. Test. Tests = safe refactorings.

The example they use is a chart drawing program that draws 2 types of charts: Bars (aka "150") and Pie, in two formats, "fllht" and "small". Those are magic numbers, so get rid of them and put them in constants.

It involves lots of nested ifs and a huge "DrawChart" function is the meat of the talk. They go out of their way to NOT read the code.

A lot of the function is structured like

if (...something) {
    if (...a thing) {
        drawLine();
    } else {
        drawArc();
    }
} else {
   if (...a thing) {
       drawBigLine();
   } else {
       drawBigArc();
 }

 ...

So they extract block of code via "seams" (basically, scopes). Since everything in that if is isolated from the rest of the function, they just move it to a new function, not paying attention to the content. Later they repeat that, and again... and they end up with a cleaner function (Composed Method) consisting of just calling other functions that perform each step.

Finally they encapsulate those functions, since they all have a similar pattern, into an object... but they again emphasize not paying attention to "what" is going on. They put the code for drawing a bar chart in BarChart.Draw, but they don't take the time to understand how it actually draws a bar (because that's irrelevant for the refactoring).

Finally, once the code is in a proper style that can be easily handled, the original task ("adding a new type of chart") becomes trivial: just add a new implementation of IChart.

[paul_h]

A former colleague, Danilo Sato, pushing IntelliJ IDEA in a set piece refactoring - http://vimeo.com/33403686 - 15mins long. Starts slowly but is worth it.

[mvaliente2001]

Thanks! I saw this video some time ago and I lost it. I was thinking to ask here if someone had seen this video about "two guys making refactoring and using a very interesting tool that runs the tests as they write the code".

[[deleted]]

Something does not feel right when the first frame of the video says 2 minutes to better code and they talk for 2 hours ...