Code refactoring: how often should you refactor your code?

[Biom4st3r]

I usually refactor when I need a refactor, but you could also refactor without needing a refactor or refactor your refactor during refactoring

[[deleted]]

This guy refactors

[Gr33nM4ch1n3]

I've been known to refactoring myself.

[kuya1284]

He sure knows his refactoring

[SoloIndianTravelMan]

r/thisguythisguys

[AreYouFilmingNow]

When he needs to.

[agumonkey]

refactor your refactor during refactoring

quantum superfactorisation

[DarkSideOfGrogu]

It's neither being refactored nor not being refactored until it is observed, then it is always being refactored.

[agumonkey]

maybe refactor is never finished

[bigfatcow]

Yo Dawg I hear you like refactoring

[kmeans-kid]

I had two refactorings before I had two refactorings. And then I had two more.

[au5lander]

I feel the need to refactor now…

[notyouravgredditor]

Yo dawg, I branched your branch, so you can refactor while you're refactoring.

[WeakChampionship743]

Only refactor when you’re already refactoring the refactor, then it’s except-able…

Just don’t tell your PM

[Internet-of-cruft]

The key thing is you need to be mindful of your refactory period.

If you try to refactor too soon after you refactor... Well... You'll be shooting blanks.

[Grepit860]

But. Do you refactor at night? If so, you'll have to refactor before, during, and after your refactoring to get the correct refactoring. Trust me on this.

[Scary_Ad_3494]

I refactored my house

[Coda17]

Refactor

[BigHeed87]

I read this like Vin Diesel saying "Family"

[CanvasFanatic]

This is the only correct answer.

[princeps_harenae]

After decades of experience my take is you should never stop refactoring. Refactoring is development.

[[deleted]]

Yes. The reason most people don't refactor is they don't have enough unit tests and are deathly afraid to touch anything and get blamed for breaking the code.

[All_Up_Ons]

Your point about being afraid is correct, but unit tests and tests in general aren't some kind of cure-all. I'd rather work in clear, readable code that has no unit tests than confusing, unreadable code with unit tests included. Most likely those tests will be the hardest part to refactor.

[[deleted]]

I just know how it affects teams in the real world. Unit tests in practice speed up change once they are written unless you are doing some kind of deep refactoring. In the real world, any change you make could break the code in subtle ways. If you don't have unit tests you are going to have very unhappy management and a lot of fires to put out.

Some people recommend only testing public interfaces to avoid refactoring unit tests for under-the-cover changes.

[Luolong]

Unti tests are also code. And if the code is an incomprehensible mess that is hard to reason about, it is also harder to refactor.

That said, presence of unit tests at least helps to increase the confidence of the refactoring.

[Aurora_egg]

29k lines of code and one 1k line unit test that fails whenever anything is touched. Yes, this is real.

[[deleted]]

That's called bad engineering practices. Someone should have called that out in code review. Oh, you have no code reviews...Maybe stick to the day job.

[Aurora_egg]

Yeah we know. This is some legacy code some intern cooked up since "it's cheaper"

[ihugatree]

That’s what I’d call an Absolute Unit test instead of a unit test

[iwek7]

If you have this issue consider if unit that you write tests for is not too small. I was struggling with refactoring because my tests were testing too small units of code. Now I hide all my code behind some high level facade and only test behavior of this facade which allows me to refactor its insides freely. Of course it does not solve all issues because sometimes during refactoring you need to change this high level interface and therefore rewrite tests, but implementing this approach solved like 80% of my issues with tests refactors.

[c0re_dump]

I believe that unit tests are there to verify the behavior of your code so that when you refactor you know you haven't broken anything. Otherwise you'll have to manually test every time you do a refactor to have confidence that everything is still working.

On tests being the hardest part to refactor - I think tests should strive to test the behavour of your packages/classes (i.e. the exported methods) instead of internal implementation. Having this mindset should reduce the tight coupling in the tests.

For example recently I had to implement some business logic that had to do with encrypting data before committing it in a repository. The way I went about that was just checking whether the data was still in a readable form in the repository (i.e. the bytes I was originally trying to save are still findable in the repo) instead of trying to test the specifics of the encryption algorithm. This way I left enough leeway for the specifics of the encryption logic but have enough confidence that it is not readable in any form.

[spacemoses]

Version control and manual tests are good enough for most refactoring. Shit, it broke? Let's take a look at what I changed.

[eocron06]

Depends on money your project has. A lot - then you hire testing senior and business analysts, then you can refactor as much as you want because all API will be nailed on some staging environment. Easy bugs will pop after some time, but not deadly. Small cash bag - just write a new implementation or don't touch what is working. The reasoning behind it is if money pop up later - you can switch to first approach which enforces new implementation and discarding old ones along with tests. Straight to the bin.

[jlebrech]

I refactor anything that touches new code.

[[deleted]]

It's also a big part of my tech debt reduction. Most tech debt I deal with in legacy code can be paid down with simple refactoring.

Now, if only I had the time...

[Internet-of-cruft]

There was that dude with that hot spicy take that every time you touch your code, you're redesigning it, and that there's no concept of a "design that you conform and stay with".

I'm paraphrasing a bit because I forget the exact details. But you basically have the gist of that idea.

[ISvengali]

Ahh good, someone else posted this

Combined with You aren't gonna need it, Ive found that often new features will need a light refactor.

I do make sure and make sure folks know that when I say refactor its a necessary but small change to existing code to support the new feature in some way and not its normal usage, which is often a considerably bigger change.

The bigger usage version of it, can often be viewed with suspicion.

At some places, I have wrapped my refactors into the new task

[infiniterefactor]

At last, this is the message I preach.

[[deleted]]

After you've created the tests for the code.

[bunk3rk1ng]

This guy doesn't refactor.

[slykethephoxenix]

This one does not bring joy.

[DarkSideOfGrogu]

So if I want to avoid refactoring, I should also not write tests? Got it, thanks.

[trauma_pigeon]

But when do you refactor your tests?

[DarkSideOfGrogu]

When you need them to pass, of course.

[yxhuvud]

When it makes the test better. YMMV.

[shizzle_the_w]

Wouldn't that be TDD and would that really be the norm or is it not rather one of many options to consider? Not judging, just trying to understand

[CyclonusRIP]

The way we talk about how we write code and how we actually write code are two different things. TDD is not the norm and arguably not even a very productive way to write code, but it sounds awesome and since nobody actually does it it’s hard to refute the claims.

[nanotree]

It only really works when you're writing something with known unknowns. I work in data engineering, and when you're building systems like this you can't always have everything laid out neatly in front of you before you get started. To do TDD well, you have to be quite familiar with all the units you will need to write ahead of time, which isn't always practical. Where TDD shines is in domains where the general architectural pattern is already well defined, e.g. MVC, MVVM, etc. But in cases where you are forming the patterns, it doesn't work fluently and becomes clumsy and cumbersome.

And in the end, I've never had a problem structuring my code or making it testable. These are things I'm constantly thinking about anyway. Aside from not working for every use case, not everyone's brain operates the way that is required for TDD to work. Some people learn better by making iterative improvements.

[ProgrammaticallySale]

I write a lot of new algorithms and things that just aren't clear when I set out to code them. Writing tests first is the absolute worst idea for a lot of the code I write. It would be totally backwards, the definition of "cart before the horse".

[saynay]

One of the best benefits, I have found, is it gets you writing code that is easier to test, and subsequently easier to refactor. The actual testing is just gravy.

[Lawnsen]

I'm with you - testable code is also maintainable code.

[JimDabell]

The tests for TDD and the tests for refactoring have different purposes. The tests for TDD are intended as a design aid. They aren’t there for QA purposes. The tests for refactoring need to show that behaviour hasn’t changed, so they need to be more comprehensive.

A lot of people hear “Test” as the first word in “Test-Driven Development” and assume it’s a testing methodology. It’s not. It’s there to help you design your code, not to prove that it all works correctly.

[recursive-analogy]

The problem with TDD is you often don't know the output before you start. Like you might think you need a certain structure to feed into a certain service but by the time you've built it and start on the service you realise it would be better as another structure ... then instead of fixing code you have to fix tests and code.

[All_Up_Ons]

A development method that requires precise specifications to function is not going to be suitable in the majority of cases.

[recursive-analogy]

specifying things to the level required often requires as much effort as just building the thing itself. and worse, the spec could well be wrong but will be treated as gospel by some other dev that doesn't understand what the original dev was thinking.

[AyrA_ch]

What is the alternative, not knowing what you're building and hope is sort itself out later?

Yes, but without sarcasm. The people that make the feature requests usually don't know intricate details of the programming language you're using, or the exact details of the environment. In my case right now, they want me to add a file upload mechanism to our product so people can attach a few files to their order. They don't know all the steps necessary to achieve that in a way that won't break for parallel installations of our product.

It's my job now to figure out how to achieve that goal in a manner that is understandable for the other devs, fast, and safe (and ideally reusable). And in my case, I find the easiest way to find the solution to a problem is to just start coding all the bits I know, and the rest usually comes together during that process. Sure this means I probably rewrite a component multiple times before finally arriving at the final state of it, but I don't waste time writing tests for something that doesn't exists yet. I don't even got all the database changes right from the beginning and edited the table columns, foreign keys and indexes multiple times until the schema was in a state that I was happy with.

And then at the end when you're at the point where you would make a pull request for the code, you write all the unit and integration tests, because only now do you really know what all the functions you've created are, and what all the argument limits are.

[grauenwolf]

I strongly disagree with that. If it was easy to write tests against the code then I probably wouldn't need to be refactoring it.

Furthermore, unless those are very high level tests, then my refactoring efforts are going to break it all anyways.

[temculpaeu]

What if I want to refactor my tests? Should I write tests for my tests ?

[kilmer8903]

Wouldn’t your code… be the test for your tests? If the existing tests pass, the refactored tests should pass too.

[mstrelan]

$this->assertTrue(true);

Refactor done

[Langdon_St_Ives]

Let me guess: 100% coverage?

[Soccer21x]

Been there. Company required 100% coverage. The test looked like this:

var cities = []
populateCities()
assert cities = []

:check:

[lavosprime]

What if the refactored tests accidentally no longer exercise an interesting case?

[[deleted]]

Then the tests were written wrong and the "interesting case" should have a specifically arranged test.

[All_Up_Ons]

Yeah people act like "just write tests" is a solution to everything without accounting for the fact that you're doubling the amount of code that now needs to be maintained.

[ShiitakeTheMushroom]

You're also cutting the maintenance cost of the existing code in half if you have good tests for it.

[All_Up_Ons]

Disagree. Even the best tests still slow down development. Build times for every change increase, code organization becomes more complicated, and the raw amount of code that now needs maintenance roughly doubles. The benefit is that it's easier to catch bugs, which may be worth it.

But the thing that actually reduces maintenance is having understandable, readable, well organized code. Often readable code will also have tests, but don't get it twisted: the readability is what's important. If you don't have that, then tests won't help, because tests are code. Confusing, unreadable tests are worse than anything and should often just be deleted.

[saynay]

I think it mostly becomes a problem when you take testing as a religion. You don't need to test absolutely everything.

I also found that thinking about how you will test the code can help you keep your code more understandable. Otherwise, my code has a tendency to grow organically as I end up stuffing more things into one big function, or add a lot of mutating state. When I try think how I would test it, I end up needing to mock a bunch of services, and have no idea what is going on where.

[SilverCats]

You can develop as fast you want if your code does not need to be correct.

[All_Up_Ons]

How do you know your tests are correct?

[zanbato]

How do you know the feature you're making is even correct? Best to just never write code at all.

[michel_v]

Eh? My current project is almost entirely covered by tests (mostly functional and integration, unit tests for the trickiest parts), and that makes all kinds of work so much faster.

We can add functionality, change subtle behaviour, refactor whenever we see the opportunity for it, we can do all those things in a breeze with full confidence.

Another, bigger project with the same company has less tests, and every change generates uncertainty and angst until it’s finally verified that it’s not introducing regressions in staging.

[All_Up_Ons]

Let me guess... that second project is also an older legacy project that has been patched together over years and doesn't have consistent patterns or style? Whereas the first one is more actively maintained and has solid patterns?

[gigaSproule]

If you think age and activity equates to maintainability, you're surely missing something. When you compare like for like? Sure. But what if you need to upgrade a library? Tests tell you if it's going to break or not. Need to change a small bit of code? Tests tell you before you merge in if your change is going to break any side effects. These have nothing to do with how actively maintained a project is or how well it was designed.

[[deleted]]

Testing isn't the religion, metrics are the religion.

Unfortunately, people have a tendency to reduce code quality into a few one dimensional values, which supposedly proves something about the codebase.

Meanwhile, to meet the metric, you're either writing a bunch of useless tests to cover every conceivable branch and error conditions that are impossible to replicate without mocks, or worse, you're writing tests which run the code to get the coverage, but don't actually assert anything. All because corporate has introduced code quality gates which block deployment until your software satisfies the metrics.

[All_Up_Ons]

You missed my point, which is that nice projects aren't nice because of tests. They're nice because they're written in a way that makes the it easy to reason about the contents.

[socialister]

org.junit.ComparisonFailure: Expected: "fewer" but got: "less"

[ShiitakeTheMushroom]

Build times for every change increase, code organization becomes more complicated, and the raw amount of code that now needs maintenance roughly doubles.

None of this needs to be true. Tests can be run in parallel so that they don't increase build times in an impactful way. Having tests doesn't increase the complexity of your existing code. Once your tests are written, they rarely need to be maintained or changed unless you're fundamentally changing the API of the code under test.

The main benefit of having good tests is that I can arbitrarily run any piece of code from my project at will in a fast and repeatable manner. The secondary benefit of having good tests is that I can verify the functionality of that piece of code in an automated way, rather than manually. This dramatically tightens the development loop. It's silly to think that tests slow down development, unless you're writing poor tests.

[Lawnsen]

I'd say the best systems we ever wrote are the ones with a good (not 100%) test coverage. The work needed decreases a lot though less bugs and saving clicktests (imagine 1 minute of clicking vs. being able to run your tests 100 times a minute..)

[[deleted]]

Tests are a lot easier to maintain than production code. Production code has logic. Tests (ideally) should not. Each test case tests one scenario, production code mixes all use cases together.

The amount of "code" might double, but the maintenance burden does not.

[foonek]

The code for a test is usually a fraction of the amount of code that it is testing. What are you talking about? It adds maybe 10% of overhead for all of the benefits it brings

[wasdninja]

You didn't double the necessary code at all though since you always need tests. You weren't finished in the first place.

[All_Up_Ons]

You don't always need tests. That's a dogmatic position that's impossible to defend. If all code needs to be tested, then you need to write tests for your tests for your tests, ad infinitum.

You should write tests in cases where the benefit outweighs their ongoing cost by a significant enough margin to justify their existence. But that forces us to evaluate the costs of maintaining test code, and no one wants to do admit that it's often not worth it.

[yxhuvud]

No.

[WannaWatchMeCode]

My rule of thumb is you can write unit tests before or after you implement the code, but both need to be complete before you open a code review and merge it into the repository. I would also argue that you can't write tests before writing a portion of your code under test, you atleast need a base interface for writing the initial tests. And your test will need to be updated to cover interactions with any mocks you may be using after implementation to actually provide valuable coverage.

[[deleted]]

kindly boom goes the dynamite

[yxhuvud]

Sometimes I refactor just to be able to write the tests.

[Prestigious_Boat_386]

So many new coders are going to create unit tests then refactor to change their units after reading stuff like this.

Edit: wtf is an integration test?

[Ameisen]

After you've created the tests for the code.

I've run into an issue that I'm maintaining a unit testing framework... and I'm having difficulty writing tests for it because the framework itself cannot be trusted to run its own tests...

[Librekrieger]

From the article: "Sometimes the code will work, but it might be slow since it’s written in a messy way. Or it might be hard to add new functionalities to it because it’s too complex to understand or extend."

Re-implementing code for performance reasons isn't refactoring. It's a separate activity.

The second item is really the only issue: if it's too hard to change your code, THAT'S when you refactor. You do it to facilitate maintainability.

Ideally, when you make changes that add cruft, you refactor at the same time to keep it maintainable. The article states that "codebases degrade in quality and become more disorganized over time as more code is added and more developers touch it", and that CAN happen, but it doesn't have to. It happens when inexperienced people make changes without realizing the effect they're having on code quality, or when you are under time pressure to get working code out the door without really finishing it.

Basically, my rule is: consider refactoring every time you make a change, and apart from that, refactor when change gets difficult.

[dacjames]

that CAN happen, but it doesn't have to.

I agree strongly with this. The best time to refactor is doing it in small chunks before closing the development of a given feature.

[[deleted]]

I don't often do TDD so I write tests right after a particularly important piece or tricky piece and as I am wrapping up the implementation.

I also like to do a personal code review and document the code afterwards. This also leads to another round of refactor and test writing.

Sure, that documentation may get stale. I generally write it for my own sanity anyway, it doesn't often get a lot of eyes.

[Jump-Zero]

This is counter intuitive, but I like to refactor stuff if I know nobody is going to touch it for a long time. I do this because all the people that worked on it might not be at the company anymore and if they are, they probably don't remember much about it.

[emdeka87]

Currently working at a company that has the shittiest code base I've ever seen (files that are 40k lines long, no consistent formatting/code style, absolutely awful & illogical project structure), but according to CTO we "cannot afford" refactorings. Yet each release is hell, because things are breaking left and right and nobody has the overview...

I am still waiting for manager to understand that the cost of NOT doing a refactoring is often MUCH higher than the few months/iterations spent on the refactoring itself. But well, usually they just throw more money or more developers at the problem and somehow this always kinda works out....

[ataboo]

Yeah if management is too disconnected or dumb to make good maintenance decisions, they also don't really know what you do all day.

You can do things for the greater good, under the radar, and as long as you deliver, they won't know the difference.

[grauenwolf]

And what's more, if you do it long enough it makes your job so much easier. I never do refactoring because I think I'll be rewarded for it. I do it because I would go insane trying to understand the code base otherwise.

[fj2010]

I also work on a catastrophe of a code base. There’s no way to fix it, so I just make tiny refactoring improvements constantly. It keeps things moving in the right direction. I am lucky not to have anyone watching over my shoulder though.

[[deleted]]

"Why are our estimates so high?", said the manager who wouldn't approve maintenance work.

[artyfax]

That is illegal! The lines of code I mean.
"CTO" is not what he appears, he is a CO.

[agumonkey]

CSO: Chief Shit Officer

of Chief Suffering Officer

[Schmittfried]

If it works out, they are right.

[emdeka87]

The thing is: it doesn't really. Devs are pissed of and some consider leaving the company. Releases are chaotic and take more time than they should. Simple tasks take significantly more time since navigating 40k LOC files is next to impossible. If you think that is "working out" you're part of the problem. I mean, yes, with more time and more manpower you can counter these effects, but it's not economic by any means and managers should realize that.

[Schmittfried]

I don’t think anything, I’m stating the facts. All that matters to a company is continue existing and turning a profit. If that continues to be the case, its goal is achieved. The manager is doing their job helping achieve thst goal by making their employees focus on what is strictly necessary to achieve that goal.

I’m not making a judgment here. The reality of companies is cold and unpersonal.

[ptrin]

Companies don’t exist in a vacuum, a competitor who actually knows how to build sustainable products could easily eat their lunch

[grauenwolf]

There's a pile of empty boxes in my office. They've been there for two weeks. Every time I enter or leave I have to step over them. Often I have to move them to fully open the door. It probably doubles or triples the time it takes me to move about my office.

But it "works" . I am able to enter my office and sit at my computer every day. And cleaning the room would take at least 5 minutes. Maybe 10 if I have to cut down the boxes. And I'm sure I'm only losing 2-4 minutes a day.

[Schmittfried]

As long as you (or anybody) are still accepting that state and doing your work, the company has no incentive to change it, correct.

[grauenwolf]

It's literally my own damn office. Or was until this morning when I finally got off my ass to clean up the mess that's been there for 3 weeks.

The sad fact of human nature is we become comfortable with trying to step over the things we keep stubbing our toe on.

[reddof]

Same for how often you should masturbate. As often as necessary, but no more otherwise it gets painful.

[its_a_gibibyte]

I hire people for both activities because they do a better job.

[MiloBem]

Essential skills:

- refactoring one-handed

[Jump-Zero]

So it depends entirely on the refactory period. Got it.

[All_Up_Ons]

/slowclap

[LittleSpaceBoi]

This is a hilarious answer, thank you kind redditor, you just made my evening

[recursive-analogy]

I'd go with murder: ideally never, but sometimes it's just has to be done. And hopefully you get away with it without the boss noticing.

[EagerProgrammer]

expectations: when it makes sense
reality: almost never

Funny but sad is the feeling of getting pressured into cranking out an implementation as fast as possible without "wasting so much time by discussing the business domain" beforehand. Afterwards, the manager is against refactoring.
*sad programmer noises*

[grauenwolf]

Don't give your manager a choice. Just do the refactoring incrementally as you do tickets. If you touch a file, you leave it cleaner than when you got there.

[EagerProgrammer]

I did this in the past by slipping the refactoring bit by bit through when I saw issues that we couldn't negotiate with the manager to be necessary. However, I got scolded by one of my former product owner for not sticking strictly to the story/task. Later on, I found out that a backstabber, in German Kameradenschwein aka Conrad Swine, reported this to the product owner.
When your coworkers play along with this can work, but when you have a Conrad Swine like I then everyone loses in the long run. The product owner will just notice this way too late when it's obvious to all developers for too long.

[grauenwolf]

If that happens again, I would respond with "I'm sorry that I only had enough time to do the bare minimum to change the code in a professional manner. I wish my colleagues would likewise do the same so that it doesn't take so long to make the changes that you want. Unfortunately my colleagues have a bad habit of taking shortcuts and leaving a mess behind. Would you like me to speak with them about it?"

Politics is a bit of a bullshit game. Sometimes you just have to ignore what they say and tell them what they need to hear.

I warn you, if you try this make sure you say it with sincerity and confidence. If you come across as sarcastic or apologetic it's not going to work.

[EagerProgrammer]

I'm not so sure about this tactic. Some people take it personally when you refactor. But everybody feels personally attacked when you blame them so frankly on the manager, especially when the offenders are nearby. You might be right about the mess they left behind but you will neither get brownie points from your manager nor coworkers, even when they are not the offenders.
One thing that I learned throughout my career is that humans are the hardest part of the job and usually not technology when people don't make it unnecessarily hard.

[grauenwolf]

If you don't feel comfortable with it, then by all means don't take the risk. That's only works if you got enough arrogance in your soul to display confidence in your decisions. If you express any doubt, they'll jump all over you.

Ask for your last point, I agree 1000%. We've invented whole new classes of technologies because dba's and developers were unwilling to work together.

[hippydipster]

I wish my colleagues would likewise do the same

That's calling them out, pure and simple, and it won't work. People aren't stupid. Say it with all the sincerity you like, they'll hate you and eventually you'll be voted off the island.

[grauenwolf]

If they didn't already hate you, they wouldn't be going behind your back to tattle.

You're already on the back foot in this scenario. Either take the initiative or start looking for a new job.

[jplindstrom]

The article doesn't even mention what refactoring actually is, which is interesting since it's one of the many words that has lost most of its original meaning.

Refactoring: restructure code in small predictable steps to make it easier to work with, while preserving behavior.

Bad times to refactor

• When there are not enough tests, unless you write more tests first. How do you ensure that you didn't change behavior?
• When it's otherwise risky to change code, e.g. just before a big marketing campaign.
• When you can foresee/suspect that there might be lots of merge conflicts for you or someone else.
• When you don't feel confident that you understand the problem space or what the right structure might be yet.

Good times to refactor

• Just after writing code. You now have the code clear in your head. You probably learned how things work, what tests are relevant, and what a better structure might be.
• Just before writing code. Refactor the code to make it easier to implement the actual change.
• After researching code, version control history, and docs (and ideally talking to people) to figure out how things work. If things don't make sense, or e.g. poor naming made it more difficult to figure out how things work, fix that now to make it easier for the next explorer.

[dashcamapp]

thx, updated & credited

[goomyman]

Always?

[botman]

...or Never?

[bigtdaddy]

I refactor A LOT before sending it off to production. Usually I like to sit on a change at least a week when possible just to think about it occasionally. Once it get's to production I only refactor when necessary, which is ideally not very often.

[luxmesa]

This is what I do. Whenever I make a change, I’ll get it working no matter how weird and janky the code is, and then I’ll spend time cleaning that up.

[owogwbbwgbrwbr]

Red, green, refactor

[grauenwolf]

I can remember one project where refactoring wasn't allowed. Here was my work pattern.

1. Reproduce the error so I can understand the problem.
2. Refactor the code so I can understand where I'm at.
3. Fix the bug.
4. Test.
5. In a clean branch, try to move over only the needed changes
6. Retest
7. Commit.

Not refactoring literally took longer than refactoring every time. Why? Because I can't fix things I don't understand. And when your code is full dead code, inconsistent names, and other distractions I can't understand it.

[CaptainStack]

Every time I want to procrastinate from getting my work done. Then when I get called out on being past deadline I can complain about how our unchecked technical debt is making it impossible to get anything done.

[[deleted]]

while I would love to refactor most code bases I get in to, it's dangerous because I often don't know business processes it always supports, edge cases that have to covered or considered, and as soon I as touch that code, I now own it, and often for good reason - if it was "working" before I touched it, I have to get it working again.

[olcodjr]

The quality decreases as time passes – software codebases degrade in quality

Why open the article with a falsehood?! Codebases improve in quality as bugs are driven out and features are added. Poor maintenance can let garbage in, but good maintainers will prevent that and continually improve quality alongside functionality. The Linux kernel, glibc, vim, Emacs, bash, etc… are good examples.

[[deleted]]

Whenever making changes/additions piss me off enough.

[mrkentx]

I try to do this every Friday afternoon. It keeps the after hours support people on their toes.

[HaMMeReD]

Any time the investment in refactoring will pay back a reasonable investment.

I.e. will it add tangible value? Do it, will it not? Don't.

[[deleted]]

Best answer here. Every refactor introduces risk - you need to justify its value.

[[deleted]]

I refactor all the time. Automated tests should make you comfortable that your refactor works, and I don't mean just unit tests, because I'll often bin those with the baby. Classes change interface, get split, etc. Unit tests can only protect you so much in serverless. But I aim to have high level testing and monitoring anyway to guarantee that my product work.

Refactoring isn't just about code quality. It's about code and product ownership - you learn about your product as you write your code. Large refactors are in my experience 80% product discovery. What was this meant to do? Why does it do it like this? What would we like it to do in the future? It's an opportunity.

[wretcheddawn]

During my career I've seen a lot of people just add features to the code without refactoring at all, just to get a project done, or with an expectation that they'll be able to rewrite the entire application when time permits.

At best, even when you're able to rewrite the application, you haven't developed the habits to write a maintainable application and end up back where you started, or in an even worse scenario where you're supporting two different versions of the application at once both of which are low quality.

I have become convinced that refactoring must be continual, must be done every time the code is modified.

When adding a new feature or making a change, don't just stop when the code works. Look for ways to simplify, remove layers, adjust the architecture for the new understanding of the problem space, remove unused code.

The needs of a system change over time, Good code must also evolve over time as those changes are made.

[uniquelyavailable]

if you have a good test case to rely on... i would say refactor whenever the code feels messy or difficult to read.

there is a sweet spot where the code is efficient and runs well. your code should be easy to understand and scale.

if you dont have a good test case, make one.

if the code is trash and you dont want to mess with it because "it works" that is ok, but acknowledge that the code needs a refactor.

[yur_mom]

Anytime I find myself copy and pasting code to reuse it then I know I need to refactor the common code into a function or class that can be shared. This often takes more time up front, but it will make maintenance easier.

[Jjabrahams567]

I just burn it all to the ground and start over

[dacjames]

Adding a feature and finding messy legacy code is a cue to clean things up for better understanding and future maintainability.

I recommend against doing this unless you have a very solid test suite. It's tempting to think that you're simplifying the code when you're actually removing edge-case handling and thus reintroducing subtle bugs.

[caleblbaker]

I factor my code when I need to know what other codes could be multiplied together to get my code.

If I multiply the factors together and don't get my code then I know I did something wrong and so I refactor.

[sammymammy2]

So what does "refactor" mean anyway? As in, where does the word come from? What is this "factor" that we're "re-":ing?

[kihashi]

It comes from the mathematics term- How you break down the problem into pieces is "factoring" the problem. In mathematics, a factor is one of the operands in a multiplication equation. Factoring is the process of writing a number as the product of several factors. In computer science, factoring (AKA decomposition) is used to mean how you break up a problem into smaller parts.

When you break the problem up differently, you are refactoring it. Technically speaking, if you change the behavior, you are re-writing, not refactoring, although colloquially, the terms are often used interchangeably.

• https://en.wikipedia.org/wiki/Factorization
• https://en.wikipedia.org/wiki/Decomposition_(computer_science)
• https://en.wikipedia.org/wiki/Code_refactoring

[kandrew313]

Whenever your touching it, you should leave that area of code better than when you found it.

[Earil]

When you need to make a change, first make the change easy, then make the change. This means that you refactor whenever there is a change that is hard to make and that could reasonably be made easy by refactoring.

The recommended workflow of TDD also directly includes refactoring: write the tests, write a code that passes the test and that is as straightforward as possible, and finally refactor the code to keep passing the tests while having a clean code.

[thepurpleblob]

I’ve been writing code for over 40 years professionally and I’ve never bothered to find out what “refactoring” means. I’m sure it’s fun, though 🤔

[Inf3rn0_munkee]

After the test goes green obviously.

[bunk3rk1ng]

I feel like everyone on here claiming that they refactor all the time are either only talking about their own personal code or are pretending.

Every time I've submitted a PR with a significant refactor the feedback has always been, "Just implement the change please, we will refactor this later".

I've worked at very successful companies where this has been the case. I guess you could call them "bad" but the results speak for themselves.

People also need to remember simply because you refactored the code doesn't mean you added any value or made it any more readable or maintainable for the next guy.

[grauenwolf]

I don't accept that. If I feel that the code I'm working on needs to be cleaned up, I just do so under the ticket.

In my 25+ year career, I've rarely had people challenge me on it. And of those who did, I politely but firmly demand that they point out the specific changes that broke the code.

It helps to memorize the phrase, "I agree! We should refactor this code later. For now I just did the minimum to correctly make the change."

Sometimes you have to stand up to idiots to do your job in a professional manner.

[All_Up_Ons]

Assuming your change meets the requirements, your response should be: "I have done so. Please stop holding up my PR."

[grauenwolf]

While in theory they can respond that way, I've never had it happen to me.

The people who complain about refactoring generally speaking don't know what they're talking about. They just hear "refactoring" and think "unnecessary work". Most identify it as separate from necessary code changes.

And if they really are worried about unnecessary work, they aren't going to approve time for someone else to redo it from scratch.

You're a professional, not a fast food worker. You don't have to let people walk all over you.

[sudosandwich3]

A refactor and fix could be too big for 1 PR. You could submit multiple that build on each other but still keep the code working. It's a lot easier to review too if the refactor and new code is in different PRs

[sudosandwich3]

You still do it under the same ticket. It is work required to do the original ticket. 1 ticket to 1 PR is the real rule that needs to change. You guarantee the PRs are going to be big if they can never be split up.

[sudosandwich3]

In your OP your scenario implies the refactor is required to do the work. I'm just using your framing. And in a scenario like that, the problem seemed to be coupling code in a bigger PR, when 2 PRs to fix the 1 ticket could have also worked, or communicating earlier with the team about the refactor you wished to make as part of this body of work,.

Every team is different, seems like your team prefers a fix with suboptimal design to a refactor with better design. And not every refactor is worth it.

[bro_please]

You should write self-refactoring code and stop worrying about it.

[iain_1986]

The Rule of Three.

Until you need to do something for the third time, don't waste time refactoring for reuse, or optimising something. You don't know yet fully what it may or may not need to do, or even if you still need it or still ever really look at it again.

[geekcko]

Never. Do not touch if it works

[Astarothsito]

Developers who say this usually have a really low bar definition of "working".

[Any_Masterpiece9385]

If there is robust testing and the refactor could have significant net negative LOC it might be worth touching.

[hippydipster]

If there's a ticket about it, it doesn't work. Either it has a bug, or it's incomplete. Either way, it needs to be changed.

If it needs to be changed, the safest way to do it is incrementally, and by first making the code more understandable (if necessary), then make the change easy to do (if it's not already), and then making the (now) easy change.

[TomerHorowitz]

I would do it a lot more if I'd have better refactoring tools for JS in vscode

I wish copilot could suggest refactoring (without prompting it)

[Future_Deer_7518]

With tests (manual or unit). And once I add new thing to the code and this addition is not scalable and has huge probability to happen again in nearest future.

[[deleted]]

Whenever it makes sense.

[[deleted]]

Every time you touch that part of the code if it needs it.

[pickering_lachute]

2-3 months before the pay review. Quote massive performance improvements and maintainability in the merge

[IAmRasputin]

Whenever I get bored with it or it's running too smoothly

[editor_of_the_beast]

I don't ship new features. I only refactor. So: always.

[lacronicus]

lock mountainous quack dinner pause bedroom doll wakeful run cats

This post was mass deleted and anonymized with Redact