Paul Hammant's Blog: Source-Control that explicitly understands refactorings
The science of source-control has a new high-bar
I blogged in 2013 on some features I would love source-control tools to-have. One excerpt:
[…] Taking it further, a source-control tool at the top level, should also be able to understand “method rename” (and other refactorings), rather than a series of adds and deletes. Another example is “method reorder” where one method/function is moved below another. There are many others that are closer to our understanding of refactoring operations.
There’s some back history, in that I paired with Lucas Ward on a Source Control Maturity Model in 2010, and that’s where we came up with a CMM inspired levels 1 through 5 for source control tools. The more recent “refactoring awareness” was to be level 6.
Source-control that explicitly understands multi-file refactoring is here. Only in PlasticSCM for now, and it’ll come later for all others I guess. Hopefully not for ClearCase <spit/>, though. The PlasticSCM have been playing with for a while now - first getting it working inside single source files (method moved up or down in C#) with their SemanticMerge technology. Now they have it working for Java and C too, and accross multiple source files. Here’s part of the built-in GUI for a C# refactoring:
Pablo Santos has made some videos of the capability in use on Windows after some VisualStudio + Resharper refactorings:
- A “very short intro” (2 mins):
- A slightly less short intro (4.5 mins):
What refactoring looks like in the hands of a master
While I think it would be the business of the IDE makers (gotta love JetBrains) to supply metadata to SCMs as refactorings happen in the workspace (versus the previous revision), Pablo’s team has implemented this as a feature within the SCM client, as they can’t wait for IDE makers to play ball. That means they’ve had to implement a bunch of refactoring-sniffing logic, and it implies that there’s a bunch of refactorings that can’t be tracked (yet). Intellij and Java are the high-bar for discrete and bulletproof refactorings, and there are a lot of refactorings on its menu, than there are on their other products PyCharm, RubyMine and WebStorm (etc).
Refactorings is a very hard topic for the IDE makers. Here’s what they all have to aspire to (if you’ve a short attention span fast-forward to 1min 10secs):
That was former colleague, Danilo Sato in 2011, demonstrating perfectly safe refactoring at relatively high speed in a “14 minute video”. More on his blog entry about that. Anyone who uses the term refactoring should watch that. As I said, Intellij IDEA is the high bar for refactoring operations, and JetBrains can’t do as much for the dynamic languages. For example “Extract Parameter” (as Danilo showed it a few times) is comparatively disabled in their otherwise excellent PyCharm IDE.
Martin Fowler on refactoring at OSCON a couple of weeks ago.
Though I was in Portland, I missed Martin’s presentation as I was in an interview for HedgeServ’s new Portland R&D office (sorry Martin). However now the video is out, I can play catch up, and Martin nails it on architecture generally (14 mins):
Martin shows a chart, part way through. A simplified version of:
(from his bliki entry DesignStaminaHypothesis)
Anyway, you get above that line, by not building up technical debt. You get above that line by doing refactorings, as you need to. Stacy Curl pointed out years ago that there’s not more useful refactorings to do, you’ve reached a desirable state called “most stable” for the codebase. Ward Cunningham, the grand-pappy of modern programming, suggested that Dependency Injection was the way architecture could be fluid on a timeline with good XP/Agile practices, rather than etched in stone as it is for the architecture of buildings. Ward was promoting the practice of injection, and was not suggesting that DI containers were a mandatory part of that. I blogged on both of those too, if you still have the energy to read more: