When to do refactoring

type

Post

status

Published

date

Aug 24, 2022

slug

refactoring

summary

We live in a world where most applications weren’t built properly from scratch. In the past days we didn't know how to build proper software; compared to nowadays, we understand much more about platform limitations and Business needs. And we even understand our business better, so we can create better applications based on business needs

password

Refactoring

Another reason for not having properly built applications is iteration-based development flow. In this case, sometimes we are staying in the position of insufficient awareness, and our initial design is incomplete.

So speaking about refactoring, it's on our shoulders to improve the legacy that comes to us.

Refactoring should be our day-to-day practice

💡

Process of development it's the constant observation and estimation of what and how needs to be refactored.

What to refactor?

Different places of application have a different frequency rates of changes.

Across all Front End applications we can highlight 3 types of logic: Domain logic, Application logic, and UI logic

Domain logic has a small frequency change.

It’s business-specific, business does not change their direction in 1 day. If you are working on some travel application, it will be aligned with travels; if you are working on eCommerce it will be aligned with buying → shipping products, etc.

Application logic changes more frequently

Application logic is how businesses imagine particular steps of communication with the user. If we need to send a notification to a user, it might be - an email, modal window, push-up, or even a request to the call center.

UI logic is changing almost all the time.

UI Logic this is all styles, layouts, spinners/accordions, translations, DOM manipulations, etc

On top of understanding the frequency of changes, we need to estimate an impact, what will be the cost of the change if we delay this refactoring, and what will be the cost if we change now.

Summary:

Domain logic has the highest return value if we extract it

Develop Application logic in a way that you will have space for future improvements

UI Logic usually is pretty easy to rework

How to do refactoring?

In an ideal application, our code represents business processes, speaks in business language, and Business can even understand their Business more by reading the code. Why do you think we have so many analytics here and there? Nowadays, our code is so unconnected with what happening in the business area. Developers thinking in programming terms/patterns rather than business terms. So we need to remember all the time, patterns are needed to satisfy a business need

I would extract a few types of refactoring:

Code Conventions refactoring

Design Evolution Refactoring

Model Evolution Refactoring

What if businesses do not allocate time to refactoring

Here is a term or even a Team Lead/Architect skill that is called Selling refactorings; surprisingly, sometimes it’s even asked during the interview process. Let’s go to the business side of the question and try to understand the business better here.

Business says: We developed something that brings money for us. Why do we need to allocate more resources and rework it? Do not touch it if it works properly.

Of course, many people say they are driven by quality but are more driven by schedule. In these cases I give my more controversial advice: Don't tell!

Subversive? I don't think so. Software developers are professionals. Our job is to build effective software as rapidly as we can. My experience is that refactoring is a big aid to building software quickly. If I need to add a new function and the design does not suit the change, I find it's quicker to refactor first and then add the function. If I need to fix a bug, I need to understand how the software works—and I find refactoring is the fastest way to do this. A schedule-driven manager wants me to do things the fastest way I can; how I do it is my business. The fastest way is to refactor; therefore I refactor.”

—"Refactoring: Improving the Design of Existing Code" by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts,

Instead of Summary

TBD