Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
tkdmatze4436yIf 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. -
TRex10386ySometime 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 -
mampf1846y@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. -
@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.
Related Rants
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.
rant
refactoring
patterns
code quality
testability