this post was submitted on 29 Mar 2024
977 points (98.3% liked)

Programmer Humor

19817 readers
44 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 2 years ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[โ€“] [email protected] 8 points 8 months ago (2 children)

You should refactor as needed as you go because refactoring cases are never gonna be prioritised.

[โ€“] [email protected] 3 points 8 months ago (1 children)

Not with that attitude they won't ๐Ÿ˜›

Refactoring in PRs just makes it more difficult to review. "Do these lines belong to the goal nor not?". Also, we're human and miss things. Adding more text to review means the chance of missing something increases.
Especially if the refactored code isn't just refactored but modified, things are very easy to miss. Move an entire block of code from one file to another and make changes within = asking for trouble or a "LGTM" without any actual consideration. It makes code reviews more difficult, error-prone, and annoying.

Code reviews aren't there to just tick off a box. They are there to ensure what's on the tin is actually in it and whether it was done well.

CC BY-NC-SA 4.0

[โ€“] [email protected] 3 points 8 months ago (1 children)

In my experience I haven't had an issue because usually the refactorings are small. If they're not I just hop on a call with the person who wrote the MR and ask them to walk me through it.

In theory I'd like to have time to dedicate solely to code health, but that's not quite the situation in basically any team I've been in.

[โ€“] [email protected] 1 points 8 months ago

I haven't had any trouble separating refactors PRs from ticket PRs. Make the ticket PR, make a refactor PR on that ticket PR, merge the ticket PR, rebase refactor PR on master, open ticket PR for review, done ๐Ÿคท

CC BY-NC-SA 4.0

[โ€“] [email protected] 1 points 8 months ago

I have a rule about this (not that I don't break it at times). I only refactor in an unrelated story if it doesn't delay deliverables and existing tests cover the code.

And you're generally right about tech that not being prioritized, but you should have a talk with your product manager/owner to strike a deal for some small percentage of your work to include tech debt. We were able to convince ours that it was otherwise affecting our velocity.