This post is my first test of zemanta's Blogspire, please tell me if you find this style of reblogging useful and I should do more in the future, or maybe I _should_ reblog, but differently. Thanks :)
Nikos Maravitsas writes about What refactoring is and what it isn't over at Java Code Geeks.
Sometimes a programmer will come to me and explain that they don't like the design of something and that "we're gonna need to do a whole bunch of refactoring" to make it right. Oh Oh. This doesn't sound good. And it doesn't sound like refactoring either....
But that other guy before me was stupid! He did it wrong! All wrong! Wah wah wah ...
Definitely something I've been guilty of throughout my coding career. Even went so far as justifying it in a blogpost where I asked _Are you a boyscout coder? _The gist of my question was whether clients should be charged for refactoring work or not.
More importantly, what level of refactoring work is on par for getting any work done in a foreign codebase and what's taking aesthetics too far.
Refactoring, as originally defined by Martin Fowler and Kent Beck, is
A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior… It is a disciplined way to clean up code that minimizes the chances of introducing bugs.
/.../
Refactoring is supposed to be a practice that supports making changes to code. You refactor code before making changes, so that you can confirm your understanding of the code and make it easier and safer to put your change in.
And that's the gist of it. You are allowed to refactor as much as you want so long as the outside interface doesn't change and you make the code demonstrably easier to work with in the future. I think any client would be happy to pay for making their development process cheaper.
Nikos goes on to explain how to refactor:
Refactoring is simple. Protect yourself from making mistakes by first writing tests where you can. Make structural changes to the code in small, independent and safe steps, and test the code after each of these steps to ensure that you haven’t changed the behavior – it still works the same, just looks different.
But there's a difference between refactoring things as you go, just polishing up some function names, changing a variable here and there, making things more readable. Those little things you have to get in order to make everyone's lives easier before you implement a new feature ... and changing the architecture of the whole system.
“Large Scale Refactoring” changes can be ugly. They can take weeks or months (or years) to complete, requiring changes to many different parts of the code. They need to be broken down and released in multiple steps, requiring temporary scaffolding and detours, especially if you are working in short Agile sprints.
This isn't refactoring!
Call redesigning and/or rewriting what it is - redesigning. If there's a business case for it, go ahead, if it makes sense to redesign now before things get messy, go ahead. For the sake of yourself and everyone around you, just don't do these things in the name of Refactoring.
Don't be that guy.
Continue reading about What Refactoring is, and what it isn't
Semantically similar articles hand-picked by GPT-4
- You can't stop the business, or why rewrites fail
- Better is good
- Don't neglect your upgrades
- Famous last words: Pfft, that's easy
- What I learned from Software Engineering at Google
Learned something new?
Read more Software Engineering Lessons from Production
I write articles with real insight into the career and skills of a modern software engineer. "Raw and honest from the heart!" as one reader described them. Fueled by lessons learned over 20 years of building production code for side-projects, small businesses, and hyper growth startups. Both successful and not.
Subscribe below 👇
Software Engineering Lessons from Production
Join Swizec's Newsletter and get insightful emails 💌 on mindsets, tactics, and technical skills for your career. Real lessons from building production software. No bullshit.
"Man, love your simple writing! Yours is the only newsletter I open and only blog that I give a fuck to read & scroll till the end. And wow always take away lessons with me. Inspiring! And very relatable. 👌"
Have a burning question that you think I can answer? Hit me up on twitter and I'll do my best.
Who am I and who do I help? I'm Swizec Teller and I turn coders into engineers with "Raw and honest from the heart!" writing. No bullshit. Real insights into the career and skills of a modern software engineer.
Want to become a true senior engineer? Take ownership, have autonomy, and be a force multiplier on your team. The Senior Engineer Mindset ebook can help 👉 swizec.com/senior-mindset. These are the shifts in mindset that unlocked my career.
Curious about Serverless and the modern backend? Check out Serverless Handbook, for frontend engineers 👉 ServerlessHandbook.dev
Want to Stop copy pasting D3 examples and create data visualizations of your own? Learn how to build scalable dataviz React components your whole team can understand with React for Data Visualization
Want to get my best emails on JavaScript, React, Serverless, Fullstack Web, or Indie Hacking? Check out swizec.com/collections
Did someone amazing share this letter with you? Wonderful! You can sign up for my weekly letters for software engineers on their path to greatness, here: swizec.com/blog
Want to brush up on your modern JavaScript syntax? Check out my interactive cheatsheet: es6cheatsheet.com
By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❤️