66
Anyone else mass-renaming env variables and instantly regretting it? (lemmy.world)
submitted 3 months ago by to c/programming@programming.dev
29 comments fedilink hide all child comments
 

Spent an hour today renaming env vars across three services to make them "consistent." Broke staging in the process because one service cached the old values. Should've just left the mess alone — it worked fine before I touched it.

you are viewing a single comment's thread
view the rest of the comments
[–] 27 points 3 months ago (10 children)

You can have both. Just not in one MR. Do what is needed, push, branch off, do what is nice

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 10 child comments
    •
  • [–] 21 points 3 months ago (8 children)

    Not if your team's policy is that every MR must be associated with a Jira ticket for a bug/feature and creating tickets for refactoring/cleanups is simply not done.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 8 child comments
    •
  • [–] 15 points 3 months ago (1 child)

    I’ve seen that before. It’s a self-destructive policy.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 4 points 3 months ago

    Usually it happens because there were multiple instances of such changes breaking stuff. Then QA team starts asking questions why are we breaking what's not broke. Also QA team works on Jira tickets, so if the change is not associated with relevant bug/feature then they won't know what needs to be tested and such breakage gets discovered too late.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 12 points 3 months ago

    I just tag it with the same ticket I was working on when I discovered it needed cleanup. My logic is, it IS directly related to that ticket because that's when the file was being touched, which implies it's time is due to clean up some of its technical debt. Nobody's ever challenged it and I see other people doing similar things. It depends on the company culture, obviously, but it's not necessarily a no-go.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 4 points 3 months ago* (2 children)

    Just make the ticket. Be the change you want to see.

    Or, as suggested, just attach it to the ticket you were working on like it’s an omnibus.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 3 months ago*

    Refactor first

    Engineering has to draw the line somewhere. Excuse my analogy, but if the order is "you are not allowed to clean up the construction site, only build", and there's so much crap around that it's no longer safe, then the answer is, "no, I can't work like this, find someone else to do it"

    That said, there is an art to working in and managing tech debt. The amazing thing about software is how flexible and how twisted it can get behind the external interface

  • permalink
  • fedilink
  • source
  • parent
  • [–] 12 points 3 months ago

    Agreed.

    I’m also a fan of Kent Beck’s “make the change easy, then make the easy change”.

    i.e. Do one PR that changes the code’s design but not its behavior, in order to make the next feature easier to implement. Then do another PR that changes just the behavior but not the design.

    This way, you get earlier feedback on refactors and you keep behavior PRs small so you reduce the likelihood of the scenario where “we really need to ship this feature but it’s tied to this massive refactor that isn’t quite right”.

    (Note that this is just for the case where a feature genuinely requires a refactor. If it’s just “boy-scouting”, then order shouldn’t matter but you should still keep them separate.)

  • permalink
  • fedilink
  • source
  • parent