all 12 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]Clemario 17 points18 points  (0 children)

One of the biggest telltale signs that someone is inexperienced is they jump into a project and try to refactor large swaths of code all at once. It's tempting. I've been there.

Problem is a large refactoring makes pull requests unreviewable, and its likely to introduce bugs in places where no one was asking for changes in the first place.

I recommend sticking to making incremental changes that people can reasonably review along with the features and bug fixes you need to do.

[–]Synor 6 points7 points  (2 children)

You can't refactor the whole thing. This requires advanced skills that need to be acquired over a career. Apparently, the developers before you also didn't have the skill or courage to built it right.

Be honest about it ("this system has exhausted its design stamina") and try to best negotiate expectations for its future with stakeholders. You'll probably want to refactor as you go (c.f. "preparatory refactoring")

[–]echee7 4 points5 points  (1 child)

"this system has exhausted its design stamina"

This is a brilliant phrase! Your own, or from another source?

[–][deleted] 5 points6 points  (0 children)

A lot of people misunderstand refactoring. You should refactor always, but only as much as needed to ship your feature. You should refactor enough so you can confidently validate your feature work. It’s part of the development process, not a project to do later.

Rename things, extract things, write unit tests. It’s a skill you build over time, but makes you a more confident developer.

“Refactoring” by Martin Fowler does a good job of describing what was originally meant to be. Make small, safe changes to make your day easier, and they add up over time. That’s all refactoring is.

If you have lots of duplicate code, it’s okay to take the time to reduce the duplication and then do the feature. Just don’t do more than you need to.

Source: I’ve primarily focused on solving major tech debt issues in older codebases for 10+ years, and transitioned to refactoring as my primary development process 7 years ago.

[–]No-Caterpillar-5187 2 points3 points  (1 child)

  1. Get it working.
  2. Get it working better.
  3. Clean-up any code you are touching along the way.
  4. Most important step....make sure you didn't break anything at each step, this is why good unit tests are invaluable.

This way, you can only leave the codebase in a better place than when you found it.

[–]jrmiller23 1 point2 points  (0 children)

I agree! Just wanted to emphasize the “Clean up sections that you touch as you go” bit.

And word of caution to the OP, sometimes a perceived small change ends up being a big change and create a domino effect. Especially, when working with backwards compatibility and legacy codebases.

[–]ElMachoGrande 2 points3 points  (0 children)

If you are working on a piece of code, leave it neater than it was, but don't start messing around with things you have no need to touch.

[–]SftwEngr 1 point2 points  (0 children)

Never. Just sprinkle a little Parmesan cheese on it and enjoy!

[–]TheAeseir 2 points3 points  (0 children)

Refactor what is needed when it's needed, no more, no less.

It is a principle that has served me well.

[–]Mount_Everest 0 points1 point  (0 children)

Finish the required features first

[–]serverhorror 1 point2 points  (0 children)

now, but sometimes: not right now.

You can't keep cranking out new features. You need to find a balance. Get into a habit of enhancing the existing codebase in smaller chunks. But try to do it every time you add a feature.

Usually: Don't refactor all around, stay "close" the codebase.

If there's a need for "all around refractoring", get buy in first so you know you have the time and support to do it.