Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
tkdmatze4632yIf 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
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
Become one with the legacy code. Good. Good. Let the hatred flow through you.
Sounds like dry/kiss legacy.
Can u link an example of antipatterns mentioned in 2 ? Thanks !
TRex10712ySometime i wonder wouldn't it take less time to create some project from scratch than modifying a legacy code with no documentation. 🤔
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
mampf2002y@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.
For legacy code, if you need to refactor something, please stop it!
You can rewrite it, but don’t refactor it.
@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.
@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
@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.