14 \ August 2019 \ http://www.phparch.comFEATUREHow to Deal With Legacy Code
Paweł Lewtak
The general opinion on legacy code is developers don’t like it. This article presents
a few ways to deal with legacy code, so it’s an opportunity rather than a source of
dread. I hope you’ll change your point of view after reading it.In an ideal world, we only write new
code, and would never have to return to
old code. In an ideal world, code written
for the first time meets all the require-
ments and is error-free. However, we do
not live in a perfect world.
The IT world is changing so dynam-
ically that sometimes you forget how
much legacy code surrounds us. I’m
sure when you hear the word legacy
code, you grimace as if you just drank
a glass of lemon juice. I want to change
your attitude. When you read this
article, I would like you to be aware
of how you can deal with legacy code
and why it’s a great way to develop your
skills. But let’s start from the beginning.What Is Legacy Code?
Let’s start by outlining what legacy
code is. A strict, encyclopedic defini-
tion^1 would say legacy code is code that
requires an unsupported operating
system, physical hardware, or other
technology that no longer has support.
It may be a language that is neither
developed nor supported. Ubuntu
has recently probed the possibility of
abandoning support for 32-bit appli-
cations—they would automatically
become legacy if the proposal passed.
Sometimes, it’s code we inherited from
someone or the old version of the
system.
Michael C. Feathers defines legacy
code as code without tests. It is a
codebase that is difficult to work with
because there are no regression tests.
According to this approach, even new,
freshly written code can be legacy if
tests do not cover it. Although we tried1 encyclopedic definition:
https://en.wikipedia.org/wiki/Legacy_codeto write it well, it can still be difficult to
test.
We often refer to legacy code as
an old piece of code nobody wants
to touch, nobody knows who wrote
it, and everyone is afraid to do some-
thing about it. At best, it’s a component
responsible for a minor function in your
product. At worst, it is the core of your
product. Whatever your understanding
of legacy code is the genesis of all cases
is very similar. Moreover, each of these
cases is a challenge for us.
We may wonder about the origin
of the legacy projects. Technologies
are not abandoned often enough and
quickly enough to explain the number
of legacy projects we deal with. Can we
say that we have a negligent approach
to our work?How Is It Made?
“Nobody sets out to write legacy
code.”- Rachel Willmer
In the history of programming, a
programmer has never come to work
and said: “Today I’m writing legacy
code.” It is never a conscious deci-
sion, let alone a bad intention. Yes,
sometimes we can do something fast,
incurring technical debt. We are less
aware of this debt, and we pay it even
less often; that is enough. Interest and
compound interest will do their job.
But it cannot be said this is the only
reason for the formation of legacy
applications. Sometimes it is the busi-
ness which does not want to invest inFigure 1. Vicious Circle