Chris Castiglione Teacher at One Month. Faculty at Columbia University where I teach Digital Literacy. I write about coding, the internet, and social impact.

Refactoring: Stop Worrying and Code, You Can Fix It Later

2 min read

Do you write perfect code on the first try?

When a writer decides to produce a novel they don’t sit down and plunk out perfect copy in one go — rather, first comes an outline, then a draft, then revisions, refinements, and finally, a publishable final draft. This process works because it lets a writer begin with big vague ideas and work through them, ironing out all the details as they surface.

Software engineers have a similar technique to editing, and it’s called refactoring. Refactoring is where a coder changes the structure of a piece of code without changing it’s function. It’s a very useful way to clean things up once your code is actually working. Most importantly, knowing how to refactor allows you to get down to coding faster, and without fear of “screwing it up.”

Lets take a look at how the writer’s pattern can be applied to converting your ideas into code.

Start With Pseudocode

Pseudocode just means “shorthand that describes code,” and it looks like plain English. I begin by writing in comments that describe the code I’m about to create, as much for my current benefit as for future documentation needs. Don’t think, just pseudocode the first approach that comes to you. The nice thing about pseudocode is that if it’s bad you haven’t wasted any time writing actual code. Once you have something that looks halfway decent, move on.

Stub It Out

Bits of code usually have an input, an output and some main variables; writing these around the pseudocode forms a sort of a skeleton called a stub.

Fill It In

Write actual code!

Iterate Until It Works

In this case, the above code didn’t work, but don’t be discouraged. Even for the most experienced coders, 90% of the job is debugging, just keep pushing until it works.

Clean It Up

Now that it works, look at your code. What’s ugly? What could be simpler? What is running slowly? Because your code is functional you can fearlessly modify it to make it better as long as you test it after each change. If it doesn’t work after a change, just undo it and try again!

Refactoring is your friend

The important lesson here is that you, like a writer, should not worry too much about the quality of your first draft because it can always be made better later. What’s great about this approach is that it works just as well for tiny snippets of code as it does for whole scripts or huge projects.

What’s great about this approach is that it works just as well for tiny snippets of code as it does for whole scripts or huge projects.

All software is made of little simple bits of code that all build up to a big complex whole. In the world of coding, we have a thing called a function or method that lets you draw a box around a bit of code, define it’s input and output, and re-use it as a black box that performs that some action.

One of the many reasons it’s good practice to write code using functions instead of copy-pasting is that if you want to change code later you only have to do it in one place (the function). Another benefit is that it’s much easier to think about small pieces of code. Once your code is working, you may notice that some functions work, but aren’t very good.

Refactoring means freedom!

Understanding refactoring means freedom from the worry of “writing it wrong”. When you sit down to solve a problem, don’t stress, remember no one writes perfect code the first time.

So focus instead on writing something that works, and remember that you can always refactor later!

Chris Castiglione Teacher at One Month. Faculty at Columbia University where I teach Digital Literacy. I write about coding, the internet, and social impact.

3 Replies to “Refactoring: Stop Worrying and Code, You Can Fix It…”

  1. Thank you very much! You saved me from doubts and showed the way to the healthy development of the project.

  2. Rubbish.

    It’s easy to say “refactor later” when you work on such a limited scoped code — which is typically an easily reversible piece of code. Try to apply that in software design, and you’ll see your codebase get rotten.

    In order to understand the pitfall of “fix it later” mentality, try to imagine a mindlessly sketched software structure containing a few high-level components, their interfaces and the way data flows between them. Then, suppose one of the components implements a sort of “blackboard pattern”, where other components store shared data for everyone’s visibility. Then, you continue to work on that “blackboard” and add some data sharing intercepting code which includes some concrete logic that should be in a separate component in the first place.

    Fast-forward 3 months and that “blackboard” became everyone’s bitch. It includes so many intercepting logic, that there’s no separation of concerns anymore. Various components depend on that “blackboard”, and (even worse) that “blackboard” has internal knowledge of external components.

    Now you can’t replace external components, because changing the “blackboard” would be a nightmare.

    I understand we can’t write perfect code from the start, and code evolves. But we shall stop promoting this “fix it later” ideology, which is basically the same as saying: cut once, measure twice later.

Leave a Reply

Your email address will not be published. Required fields are marked *