Coder, writer, nonconformist 🤘
Ex-SWE @ Facebook 🤩
Sharing experience and notes on building a career, sharpening coding skills and creating great things 🏆
Austin, thank you for your reply and great points!
I feel that what you lay out here is exactly how I or many engineers I've worked with perceive refactoring. This isn't bad in any sense but is a little bit blurry.
(Also the term "rewrite" didn't seem to be the best fit to me. I just couldn't find a better word since I am not a native English speaker.)
It's like any time you rewrite the code, for whatever reason, you may refactor it along the way, whereas when you intentionally refactoring thing, you sometimes feel insecure about the changes it introduces. Either because it may be harder to bisect change history in search for bugs, or because test coverage is low or absent, or whatnot.
However, after watching Martin Fowler's wonderful talk I referred to in the article linked to this post (yes, I am urging you to read it, even though there's not much to add to what you already know), I realized that the definition and mind model of refactoring I have been using for years and always been perfectly understood by my peers, may be a of a bit wrong or inclomplete definition.
a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior
On top of that, it's by his definition a sequence of small changes:
Its heart is a series of small behavior preserving transformations. Each transformation (called a "refactoring") does little, but a sequence of these transformations can produce a significant restructuring. Since each refactoring is small, it's less likely to go wrong
I am not saying Fowler is god, even though he invented the discipline as far as I am concerned. It just feels that having small refactorings applied sequentially eases this anticipation of trouble you may have after a massive transformation introduced by something that combines both refactoring and changing code behavior. To me, after years of practicing programming alone and in teams, it for some reason feels a bit like revelation.
Extracting a method, then renaming a variable, then splitting loops, and extracting methods again seems so much more safe to me now than what I used to do.
I'm a Systems Reliability and DevOps engineer for Netdata Inc. When not working, I enjoy studying linguistics and history, playing video games, and cooking all kinds of international cuisine.
As a general rule, I do find that it is often better to refactor in small steps like this, at least while you're working on things, for three reasons:
It makes it easier to keep track of what's actually happening (especially important for code review).
It makes it easier to track down what change accidentally introduced a bug.
It lets you test the changes incrementally as you go along, making it easier to spot bugs before they happen.
Sometimes though, it really does make sense to just do it all at once because the intermediate states are either nonexistent or just plain meaningless. Switching the internals of a function from an iterative implementation to a recursive one is an example of something like this, there's just no sensible 'intermediate' state for such a change, so it makes no sense to try and step through one.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Austin, thank you for your reply and great points!
I feel that what you lay out here is exactly how I or many engineers I've worked with perceive refactoring. This isn't bad in any sense but is a little bit blurry.
(Also the term "rewrite" didn't seem to be the best fit to me. I just couldn't find a better word since I am not a native English speaker.)
It's like any time you rewrite the code, for whatever reason, you may refactor it along the way, whereas when you intentionally refactoring thing, you sometimes feel insecure about the changes it introduces. Either because it may be harder to bisect change history in search for bugs, or because test coverage is low or absent, or whatnot.
However, after watching Martin Fowler's wonderful talk I referred to in the article linked to this post (yes, I am urging you to read it, even though there's not much to add to what you already know), I realized that the definition and mind model of refactoring I have been using for years and always been perfectly understood by my peers, may be a of a bit wrong or inclomplete definition.
Martin Fowler defines refactoring as follows:
On top of that, it's by his definition a sequence of small changes:
I am not saying Fowler is god, even though he invented the discipline as far as I am concerned. It just feels that having small refactorings applied sequentially eases this anticipation of trouble you may have after a massive transformation introduced by something that combines both refactoring and changing code behavior. To me, after years of practicing programming alone and in teams, it for some reason feels a bit like revelation.
Extracting a method, then renaming a variable, then splitting loops, and extracting methods again seems so much more safe to me now than what I used to do.
Does this resonate with your experience somehow?
As a general rule, I do find that it is often better to refactor in small steps like this, at least while you're working on things, for three reasons:
Sometimes though, it really does make sense to just do it all at once because the intermediate states are either nonexistent or just plain meaningless. Switching the internals of a function from an iterative implementation to a recursive one is an example of something like this, there's just no sensible 'intermediate' state for such a change, so it makes no sense to try and step through one.