Tool Up!

I refactor ruthlessly. I refactor just to see what it’d look like – then throw it away. I change a name 5 times in a row just to see how it looks in context.

In attempting TDD one really big way to screw up is to gloss over the refactor step. Maybe part of that is pressure to move on to the next task, but some for some people it seems to take effort.

Now I usually write C# in Visual Studio and ReSharper. This means I can do things like:

  • Rename a variable/method/class/interface
  • Extract a variable/method/class/interface
  • Navigate easily between related code elements

Not only can I do them, but the work to do them is approximately equal to thinking them. This is because the IDE understands the structure of code, including scoping and naming rules.

Hooray, life is good.

But sometimes I end up writing with other people in their language/editor of choice, and I just think “where are your tools?”.

Today I did a code kata with someone in php using a mixture of gedit and vim. It was nightmarishly tedious to refactor anything. Renaming a variable needed a regular expression. What if a method had a similar name? There are a load of compile errors to fix.

This isn’t the first time I’ve run into this issue – on multiple occasions when I’ve used a different language (PHP, C++, F#) I’ve found the same thing (Java in Eclipse being the exception). Have I just been unlucky, or are lots of people genuinely working without these tools?

Most people who write software are surely bought into the premise that good software can make a job easier and more efficient?

Apply it you your own job, tool up!

Disclaimer: The company I work for does sell tools to help developers – that’s not why I’m writing this.


About GrahamTheCoder

I'm a C# developer based in Cambridge hoping blogging will achieve some or all of the following. Help me organise my thoughts. Practice writing things other than code. Give me a place to refer people to when I'm trying to make a long winded point. I welcome comments and constructive criticism, and hope to look back at my written opinions in the future and laugh at my own naivety.
This entry was posted in Principles and tagged . Bookmark the permalink.

2 Responses to Tool Up!

  1. Have I just been unlucky, or are lots of people genuinely working without these tools?

    I’m one of those eejits that tends to write without tooling, at least when writing Python or JavaScript. I do use the refactoring tools in Eclipse and Visual Studio when doing Java or C# respectively. The great advantage of the refactoring tools in those languages is that they rarely make mistakes. The more dynamic nature of Python and JavaScript makes it harder to, say, find all the places that a method is called.

    For the code that I work on, time spent manually refactoring is dwarfed by working out what the right refactoring is, and how that would impact the rest of the code. For instance, if I’m renaming a function that’s used in a few places, I’m probably going to visit a few of the use cases anyway to see the impact of the refactoring.

    The time when it’s particularly painful is on a large codebase where the function is used in many places. One argument is to avoid large codebases in the first place, although that’s a bit of a cop-out since that’s not the position we often find ourselves in. It does also raise an interesting point: if you’ve split your code into multiple components, then changing the API of one of those components becomes more painful than if everything lived in a single, monolithic component and you could automatically refactor across files. The approach to mitigation then becomes to make the API as minimal as possible, which is probably a good thing to encourage anyway. (Alternatively, providing an automated script that allows users of your library to automatically fix their code is extremely funky, but also extremely rare.)

    Anyway, assuming we have a large codebase, then having to manually refactor might tell us one of two things. First: that we’re changing a core function that’s unavoidably used in many places. This reminds us that there’s a cost to refactoring: even if we’re picking a better name, then there’s a cost of having the rest of the team learn and remember what that name is. Second: we’re changing a function that’s used in too many places, and those use cases should rely on another layer of abstraction rather than that function directly. We can still find those things out when using refactoring tools, but they’re easier to ignore.

    So, to try to be a bit more pithy: it would be nice to be able to use those tools in other languages, but it’s not a big problem for me, and manually refactoring does allow consideration of some things that can be missed when automatically refactoring.

  2. It is trickier to write/get refactoring tools for more dynamic languages. I hear that ReSharper has valiantly added some level of Javascript support that uses TypeScript bindings to aid analysis. Though in Visual Studio you might as well use TypeScript itself if you’re trying to write maintainable code.

    To work out the right refactoring I like to try things out. Admittedly, a few manual changes and some imagination may be sufficient for seeing what a refactor might look like – it needn’t compile/run.

    For projects I work on, I find that there are some (maybe 5%) refactors that require serious thought/discussion – those are really important. However, most just fall out on their own as a series of small changes each fixing an obvious issue such as naming, or breaking SRP.

    Changing an API can indeed be messy across Visual Studio solutions, but worst case you can import the dependency as source temporarily and redo the refactoring keypresses. Hopefully someone will write a nice tool for code migration, then I’ll sound more consistent when advocating both small solutions and maximal use of refactoring tools.

    Number of files in a changeset should flag up an overly referenced item during a refactor. Code navigation tools available in Visual Studio + ReSharper massively downgrade the importance of remembering all the names – knowing any name in the general area is fine. The name is obvious post-refactor anyway right? 😉

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s