Refactor First

Upcase
1
In this episode, Ben shares a story of how he screwed up but still had some good come of it. Further reading: Kent Beck's tweet When to refactor
This is a companion discussion topic for the original entry at https://thoughtbot.com/upcase/videos/refactor-first
2
  • “It’s much easier to review something if it’s either refactoring or new functionality, but not both”
  • “Everyone loves a small pull request”

I completely agree, and have used these techniques successfully.

I’ve found some challenges though. It seems you need to have a fairly short cycle time for getting PRs reviewed and approved. If you work asynchronously then this can sometimes take several hours (or if you don’t work asynchronously then you have to continually switch context whenever you get a GitHub notification, which can be very disruptive).

I’d be interested to hear how you guys distribute PRs at thoughtbot. On teams I’ve worked in previously I’ve seen various approaches, for example a chatroom where the URLs of all new PRs are posted (e.g. HipChat hook for GitHub), or some kind of random auto-assigment (e.g. using Hubot).

3

So true. It’s a very tough balance.

I try to be very quick to get to PRs, and I think other thoughtbotters do too, since it’s no fun to be blocked while waiting for review.

You do sacrifice personal zone-time and focus though. I’m not sure there’s an easy way around this.

As for distributing reviews, we just post a PR in the chat room and whoever grabs it first takes it.