• autoexec@lemmy.blahaj.zone
    link
    fedilink
    arrow-up
    72
    ·
    9 months ago

    But you should probably touch it before all the dependencies are outdated. And before everyone who understands how to work with it has left. Especially if it happens to be core to the business.

    :)

    • BleatingZombie@lemmy.world
      link
      fedilink
      arrow-up
      17
      arrow-down
      1
      ·
      9 months ago

      I completely agree. I think “touching” is the right word. Don’t rebuild it, update as needed and get familiar (if needed)

    • Bappity@lemmy.world
      link
      fedilink
      English
      arrow-up
      10
      ·
      edit-2
      9 months ago

      had to completely replace a component in a massive project at my work recently because we forgor how it worked and had a newer different thing for it. it was so intertwined into that project that I practically had to do a ship of Theseus on it 😭😭😭😭

    • Moops@lemmy.world
      link
      fedilink
      English
      arrow-up
      20
      ·
      edit-2
      9 months ago

      I mean, runtimes can be a legit reason to say something’s not working.

      • pearsaltchocolatebar@discuss.online
        link
        fedilink
        arrow-up
        14
        ·
        9 months ago

        But it does work. Eventually.

        Really, I fixed it because we’re doing an OS upgrade and I didn’t want to wait 2h every time I spun up a new instance to test a change.

  • lobut@lemmy.ca
    link
    fedilink
    arrow-up
    21
    ·
    9 months ago

    Well over a decade ago I remember a coworker would just go through the codebase and add his own coding style.

    Instead of if (predicate) {

    He would do if ( predicate )

    I would always ask why he did it and he said, “well we don’t have any coding standards so I’m going to do it” … I replied, “there’s things like unwritten rules and sticking to whatever’s in the codebase makes it easy”. I told the seniors and they chose not to do anything (everyone just merged into trunk) and they just left him for a while.

    Then he turned rewrote built-in logical functions in code like this: if (predicate || predicate) {

    Into code like this: if ( or( predicate, predicate ) ) {

    This was C# and there was no Prettier back then.

    Also, he would private every constructor and then create a static factory method.

    Eventually the seniors told him to knock it off. All I said was that I initially tried telling them weeks ahead of time and now we got a mess on our hands.

    • Electric@lemmy.world
      link
      fedilink
      arrow-up
      18
      ·
      9 months ago

      Hilarious but their fault for not making a standard. The guy was just taking the initiative.

    • SavvyWolf@pawb.social
      link
      fedilink
      English
      arrow-up
      9
      ·
      9 months ago

      The best part is that his “or” function changes the semantics of the code in a subtle and hard to find way. :D

  • haruki@programming.dev
    link
    fedilink
    arrow-up
    20
    ·
    9 months ago

    This is actually not a good advice, from my experience. If we don’t monitor, refactor, or improve the code, the software will rot, sooner or later. “Don’t touch” doesn’t mean we don’t ever think about the code, but we make the conscious choice not to modify it.

  • Vlyn@lemmy.zip
    link
    fedilink
    English
    arrow-up
    15
    ·
    9 months ago

    Yeah, I’ve worked with the leave it alone types. What do you get in return? Components of your system which haven’t been updated in the last 20 years and still run .NET 3.5. They obviously never stopped working, but you have security concerns, worse performance (didn’t matter much in that case) and when you actually need to touch them you’re fucked.

    Why? Because updating takes a lot of time (as things break with every major revision) and on top of that if you then decide not to update (yeah, same coworker…) then you have to code around age old standards and run into bugs that you can’t even find on Stack Overflow, because people didn’t have to solve those in the last 20 years.

  • wabafee@lemm.ee
    link
    fedilink
    arrow-up
    14
    ·
    edit-2
    9 months ago

    Or you do the right thing re-write or refactor, apply the latest practice add some tests to it. This way you won’t have a black box anymore. Who knows there might be a hidden bug there that might be a huge security issue and could bite you back in the future.

  • tsonfeir@lemm.ee
    link
    fedilink
    arrow-up
    7
    ·
    9 months ago

    I’m a big fan or refactoring and rewriting my code as often as I can. Not only does it keep my brain “on topic” but it allows me to make major improvements. Nothing will ever be perfect. Just try to leave it in a better state than it was before.

  • kamen@lemmy.world
    link
    fedilink
    English
    arrow-up
    5
    ·
    9 months ago

    No, we must rewrite it in this fancy new framework that came out last week.

    (/s if not obvious)

  • OttoVonNoob@lemmy.ca
    link
    fedilink
    arrow-up
    5
    ·
    9 months ago

    Its ok to touch up code. If you have lots of notes, on what its supposed to do… I learned this the hardway.