http://www.phparch.com \ August 2019 \ 17How to Deal With Legacy CodeRefactoring, in turn, allows you to
replace the old code with new slowly.
Take a function, class, or module
and rewrite it. It is necessary to have
automatic tests or write them before
changing the code. Otherwise, it is diffi-
cult to verify that you have not broken
anything. As a result, the application
should work without any changes for
the end-user. You don’t have so much
freedom here as in the case of rewriting:
you won’t change the language or frame-
work. You can try using microservices,
but that’s a topic for another article.
The refactor should be easier to sell to
the business. Imagine you are a project
manager and you hear from program-
mers: “We want to freeze this project for
four to six weeks. During this time, we
won’t patch bugs or add new features
as we rewrite the application. After
that time, you get an application that
does the same thing, but it’ll be easier
for us to develop it.” Along comes the
second team saying: “For the next four
to six weeks we’ll be slower to develop
the application while we devote some
time to improving the quality of the
code.” Keep in mind that programmers
tend to underestimate, and those four
to six weeks might turn into four to six
months instead. Which option would
you choose?
When we put it this way, it may seem
that refactoring is the only reasonable
solution. But as in most cases, here too,
the answer is: it depends. If you plan to
change architecture, e.g., from mono-
lith to microservices, this is an excellent
opportunity to rewrite the code, and
sometimes there is no other way out.
If you are going to touch the core busi-
ness, it is better to choose to refactor.
The business part of the application is
too important to afford breaks in its
operation or the introduction of new
bugs. Customers might wait, but the
competition does not sleep—you can
not afford to write code from scratch in
such a case. If you still have the authors
of the original code in your team, they
can share their knowledge, ideas from
the past, and help you understand the
code. If you don’t have such peoplewithin reach, maybe it’s a waste of time
trying to understand the unclear code?
Interestingly, the most competent
person to rewrite the code is the author
of the original code. Martin Fowler, on
his blog, recalled a conversation with
team leaders. The project they just
implemented was considered a success;
the client was satisfied; the project was
completed on time and on budget, etc.
Programmers were satisfied with the
final result, almost idyllic. The leader
was generally satisfied, but for some
reason shaking his nose at the chosen
architecture. Fowler asked him why.
After all, he was one of the most expe-
rienced architects. He answered: “We
generally made good decisions, but
only now do we know how we should
have built them.” The team that imple-
mented the project from scratch and
managed deployment knows code
the best. The same team can point out
which decisions were wrong in retro-
spect. That knowledge gives the same
team leverage in case of rewriting the
application from scratch. With that in- Getting started with Elasticsearch
- Defensive coding practices
- Local development environments
- Maura Teal (@mlteal) on scaling
WordPress and speaking at php[world]
Listen to Episode 22: