30
mampf
2y

How I spend my days at work working with legacy code:

* Writing tests before I do anything
* Noticing that i cannot write tests because of antipatterns. Lots of them.
* Refactoring to make at least a tiny bit testable.
* Then writing tests.
* More rewriting and refactoring
* Finally adding that one feature my boss asked me for
* Writing tests for that new feature (my do that before implementing)
* Explaining to my boss why it took me so long and agreeing on stopping writing tests.
* 2 days later: explaining why i still broke something.

But in the end my code works just fine.
my colleagues handle things differently. They just ignore problems as long as at least one feature works a bit.

Comments
  • 2
    If you exchange the first point with

    Write tests to understand what that piece of code really does

    We have the same way of dealing with legacy code
  • 3
    i came to realise that testing legacy code written without testability in mind is too often a waste of time
    i eventually write tests just to show how something works, instead of comments. but that's it

    in those cases i normally ask analysts/testers to perform integration tests and look for regressions

    quick'n'dirty driven development
  • 2
    Become one with the legacy code. Good. Good. Let the hatred flow through you.

    Sounds like dry/kiss legacy.
  • 0
    Can u link an example of antipatterns mentioned in 2 ? Thanks !
  • 0
    Sometime i wonder wouldn't it take less time to create some project from scratch than modifying a legacy code with no documentation. 🤔
  • 0
    How I find myself doing it

    1. find legacy code
    2. create a ticket to refactor it
    3. it gets pushed to an obscure release somewhere in the future
    4. people keep finding and fixing bugs
    5. one new feature
    6. 100 new bugs
    7. people finally pick up we may have to refactor it, but first fixing the 100 bugs because they are in production releases and customers are seeing them as issues
  • 1
    @mousta3milism nothing of my company is public so far. But... Final class, private constructor, and a getInstance-method. A lot of side effects because clssses need to call an initialized () method.

    Such things. Hard to mock, and I don't bother with powermock. Especially when you want to call a real method from the mock.

    It's sometimes easier to just extract abstract factories and rewrite and restructure large parts, after you understood how and why they do something.
    But often enough, you wonder why they did this in the first place.

    Long story short... I'm now quite skilled at refactoring (i think) and I'm not afraid to rewrite large parts of code. We have lots of tests to do for each release anyway, which helps a lot.
  • 1
    @TRex probably.

    Sometimes it's just hard to understand the legacy code. And by the time you have rewritten posts to überstanden things, you can just continue on that code
  • 0
    For legacy code, if you need to refactor something, please stop it!
    You can rewrite it, but don’t refactor it.
  • 1
    @sunfishcc absolutely refactor the section you have to be responsible for.

    But feel safe doing so. Eclipse, Visual Studio, and other tools have [highlight] -> right click -> extract class or method or rename variable.

    These tools will keep your refactor stable and your changes fast.

    I would use a Dry/Kiss/SO of SOLID approach. Since LID can add even more boiler plate. Do what it takes to get the job done cleanly.
  • 0
    @tamusjroyce There’re tools like reshaper, could do a better job than vs‘s buildin refactor.
    The problem is legacy code are done with different format, convention, standard. And they’ve been proven working just fine.
    Simple refactoring often break things. Eg. mixin can’t be defected by refactor software.
    Write new class/method to do the same work will provide to testable fresh start point
  • 1
    @sunfishcc Yes. Great point. Don’t refactor everything. Refactor as little as you can. Only a small portion of a class should be our responsibility. But you do need to refactor legacy code. Just don’t go wild.

    VS2017 is much better now. Though resharper gives you some great features. After using it for a few years, I learned what I need and no longer use it.
  • 0
    @mampf thank u, I understand better now !
Add Comment