Making Code Speak

A weblog of tools, techniques, styles and habits for programming with fluency.

Refactoring When The Tooling Isn't There

So Justin Searls wrote a great post the other day on The Failures of “Intro to TDD”, and then Bob Martin wrote a great counterpoint to it. Both the posts are well worth reading, though these days I find that the latter of the two is closer to my own practice. But what I really want to talk about is Angela Harms’s response, calling attention to the way Bob Martin’s article is shaped by working in languages with strong refactoring tools:

Bob describes the TDD I know & love, but also mentions alt-ctrl-m, which is not something our JavaScript friends have access to. Wondering.

— Angela Harms (@angelaharms) January 29, 2014

This got me thinking! See, I recently experienced this contrast firsthand. From 2011 to 2012, I got to see what changed in the experience of working on a large Java project while we introduced Groovy into the code base – consciously trading in easier refactoring for a more flexible and dynamic language. I don’t think it made us more afraid of refactoring, but I do think it took conscious effort to keep the habit up as we lost tool support for it. I thought I’d take a few minutes this evening to think through what helped:

@angelaharms @stevejxsn @joelhelbling Going back to step by step instructions in @martinfowler’s book works. More keystrokes, but not hard.

— George Dinwiddie (@gdinwiddie) January 29, 2014

And remember: languages with poorer refactoring tools often have richer, more expressive syntax. This makes it harder for an IDE to refactor your code automatically, but means that you can make more meaningful changes in fewer lines of code.

posted by Moss on 30 January 2014