Here is a poorly written function to change the price of a product that takes into account many different conditions. You need to refactor, since the function itself is terribly unreadable. Where to start refactoring or what methods to use to start refactoring?
I tried to find a service for automatic refactoring or code analysis, I did not find anything.
Where to start refactoring or what methods to use to start refactoring?
In unit tests. If you don't have them, this is where you start, by writing them. Otherwise, how you'd know you didn't break anything? By writing unit tests, you also would have a chance to understand what this code is actually doing in the first place.
My go-to methods of refactoring are all about clarity and organization:
1. Rename for clarity of intent
2. Extract to eliminate duplication, and to push down implementation details
3. Compose to achieve a single level of abstraction (SLAP)
These refactorings are fairly simple and safe to do, especially if you have local variables or limited scope variables. If you have an IDE that can do automatic refactoring, all the better, since that's much safer than manual refactoring. If you're not disciplined and methodical, manual refactoring is dangerous and could lead to breaking the current functionality.
It's important to have tests that will tell you if you broke something while you were refactoring. Without that safety net, refactoring is risky at best. Rename and Extract + Compose are the least risky of all refactorings I know and they can help you loosen up tightly coupled code enough to be able to add unit tests for isolated sections of the code.
Here's what I mean by using Rename/Extract/Compose:
This only illustrates the idea of extracting a section of code that does one small job so that the big method starts becoming a Composed method. You'd do that multiple times for various sections in the big method until it's only a few lines of code consisting of calls to the extracted methods.
The name strawberry is used on purpose to force you to think of a better name, so you can Refactor-Rename. This is a strategy I learned from Arlo Belshee's Naming is a Process
the topic of "refactoring" is very interesting, it might be worth looking at the book "Practical Design Patterns for Java Developers" (https://a.co/d/6EPQuiq)
It explores over the chapters through the proposals how to approach challenges.
If I look at the examples in the thread, the book can give you a guide on how to use the design pattern through refactoring, because IMHO one of the goals of refactoring is maintainability.
True, I forgot to mention it implicitly. Refactoring requires creating a sufficient set of tests. Since it is being refactored, IMHO: I would consider that the codebase under consideration may contain a hidden problem that is not consistent with the business scenarios or intended technologies. Therefore I'd select the "lowest" layer from the desired high level abstraction, could be for example client as todays apps are very often emitting data over http layer (TCP/IP). And start producing a sufficient coverage (TDD like approach).
Then changing the code base accordingly by following OOP,APIE=>Design Patterns to produce maintainable, understandable and extendable result.
This may also support also another software development approaches like Domain Driven Design, Even Driven Design or etc.
therefore I've referenced the book above "Practical Design Patterns for Java Developers" (https://a.co/d/6EPQuiq) as there are sections exploring those approaches,
Hope it helps!
It wasn't my idea to go to some crazy nightclub in the middle of nowhere. I just wanted to stay home and cuddle with this tiny ad:
a bit of art, as a gift, the permaculture playing cards