1125
The Six Stages of Code Grief (suppo.fi)
submitted 11 months ago by to c/programmer_humor@programming.dev
142 comments fedilink hide all child comments
 
you are viewing a single comment's thread
view the rest of the comments
[–] 22 points 11 months ago (9 children)

I just inherited my first codebase a few months ago. It's like this everywhere and original developer was fired, so what should sometimes be a simple fix turns into a full day of finding what needs to change. Any recommendations on fixing/maintaining code like this or should I just make it the next person's problem?

  • permalink
  • fedilink
  • source
  • hideshow 9 child comments
    •
  • [–] 34 points 11 months ago* (6 children)

    • if it's not in git / SVC, add it as is. Create a "refactor" branch, and liberally use commits

    • Treat it like a decompilation

    Figure out what something does, and rename it (with a stupidly verbose name, if you have to). Use the IDE refactor tools to rename all instances of that identifier

    • Take a function, figure out what it does, and refactor it in a way that makes sense to you

    • Use the editor's diff mode to compare duplicate code, extract out anything different into a variable or callback, and combine the code into a function call. Vscode's "select for compare" and "compare with selected" are useful for this

    • Track what you're doing / keep notes in something like Obsidian. You can use [[Wikilinks]] syntax to link between notes, which lets you build a graph structure using your notes as nodes

    • be cognizant of "Side Effects"

    For example, a function or property, or class might be invoked using Reflection, via a string literal (or even worse, a constructed string). And renaming it can cause a reflective invocation somewhere else random to fail

    Or function or operator overloading/overiding doing something bizarre

    Or two tightly coupled objects that mutate each other, and expect certain unstated invariants to be held (like, foo() can only be called once, or thingyA.len() must equal thingyB.len()

    • write tests if you can, either using a testing framework or custom Python scripts

    You can use these to more thoroughly compare behavior between the original and a refactor

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 16 points 11 months ago (4 children)
    • if something feels too "heavy", like it's doing xml formatting, file manips, a db insert, and making coffee, all in a single class or function

    Separate out those "concerns", into their own object/interface, and pass them into the class / function at invocation (Dependency Injection)

    • use "if guards" and early returns to bail from a function, instead of wrapping the func body with an if
    
public Value? Func(String arg) {
  if (arg.IsEmpty()) {
    return null;
  }
  
  if (this.Bar == null) {
    return null;
  }

  // ...
  return new Value();


  /// instead of

  if (!arg.IsEmpty) {
    if (this.Bar != null) {
      // ...
      return new Value();
    }
  }
return null;
}
  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 1 point 11 months ago (2 children)

    I always feel bad about putting little ifs at the top of functions. Is it not bad practice? I like them because they're simple to implement modify and read, but I have this voice telling me I need to make things more impressive.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 11 months ago

    Never make things more "impressive"

    Make them more comprehensible

    Reduce the cognitive load required to understand and reason about a piece of code. Honestly, the more you can express complicated ideas simply, the more impressive you are

  • permalink
  • fedilink
  • source
  • parent
  • [–] 2 points 11 months ago* (last edited 11 months ago)

    I started putting a helpful comment above the ifs as a seperator to cope with that.

    public Value? Func(String arg) { 
  // Sanitize.
  if (arg.IsEmpty()) return null; 
  if (this.Bar == null) return null; 
  // Get [that] and/or do [this].
  var foo = this.baz.foo;
  ...
  return new Value();
}
  • permalink
  • fedilink
  • source
  • parent
  • [–] 4 points 11 months ago* (last edited 11 months ago)

    You're going to want to follow the "campsite rule" everywhere you go, and also sneak in positive refactors into your feature changes (if business is not willing to commit time to improving the maintainability of the codebase).

    Read up on good software design principles. I don't know you experience level, but for instance, everyone agrees that appropriate abstraction, and encapsulation make code easier and more enjoyable to work with, and will let you run tests on isolated sections of the code without having to do a full end-to-end testsuite run.

    Having tests that you trust, especially if they execute quickly, will increase your "developer velocity" and let you to code fearlessly--knowing that your changes are reasonably safe to deploy. (Bugs and escaped defects will happen, but you just fix them and continue on.)

    Good luck!

  • permalink
  • fedilink
  • source
  • parent