16 \ August 2019 \ http://www.phparch.comHow to Deal With Legacy Codebuildings. There everything is planned,
measured, weighed, tested, and simu-
lated in advance.
In programming, we rarely know
100% of the requirements, and that
is the charm of the Agile approach.
Businesses usually have a general idea
about how they would like to achieve
their goals and how we can help. As
the implementation of subsequent
elements of the system progresses, the
client gets another tangible piece of the
puzzle and allows themselves to change
the requirements during the project.
Add to this the changing technologies
and tools that need to be learned on an
ongoing basis to stay in the loop.
Imagine that the client of a skyscraper
would like to increase the height of
each floor by 10 centimeters after the
construction of four floors, and when
the whole thing is stable adds two or
three more floors for an underground
car park.
Probably not possible in the phys-
ical world. In our world, everything is
possible. It is only a matter of time and
money, and this is how we approach
writing code. We have an idea to do
something generic, with a carefully
selected architecture. The idea is that
it develops easily in the future, and the
introduction of new features is just a
matter of configuration in a perfect
world.
Fear Factor
Generally speaking, legacy projects,
when we talk about the existing code,
struggle with a lack of documentation.
Knowledge of all the features that have
grown up over the years is not evenly
spread throughout the team. In such
a situation, it is not surprising that we
do not know the code that preceded
this code, and whether the code does
what it’s supposed to do. In the worst
case, the original author of the code
decides to look for challenges outside
the company’s structures. Then, the fear
of changing anything manifests in the
team.No Tests and No Documen-
tation
Both are classics. In legacy apps, we
rarely see tests. The few we find may
not always be valuable. Generally, you
should expect before looking into
the code that tests are not there. Lack
of tests takes away, first, the ease of
refactoring, and secondly, additional
documentation to the code, which
would show how to use this code in
practice.
The second noticeable thing is the
lack of documentation. While some shy
attempts to write tests happen, adequate
documentation is like the holy grail. I
remember a situation a few months ago
when I reached for one of the projects
I wanted to go back to. I looked at the
source code, and at first glance, I did
not know how to configure and run it.
Suddenly I see a README file, small,
but better than nothing. I open it, and a
few sentences are describing the proce-
dure of installation, configuration, and
launch. I was so shocked that I still have
it in my memory. When writing code,
we do not think about documentation,
because you write the code yourself,
and besides, you have a good memory,
and you should remember everything.
If you prepare a piece of documentation
and you find it after a few months, when
it’s most needed, I assure you that you
will be more conscientious preparing
documentation, even the residual one.Don’t Complain
Don’t complain about the code and
don’t whine if you don’t want to work
on improving the code. Complaining
just for the sake of complaining gener-
ates harmful noise that serves no
one. What’s more, it can build a nega-
tive atmosphere around the project.
Complaining makes you a victim, not
an actor as you should be. This behavior
is an infectious and harmful approach,
especially if you have less experienced
people in your team. Think: “Is such an
attitude is something they should take
as a model?”
It’s the same as cursing around chil-
dren. Parents try not to do this so thatthe children won’t learn the language.
Similarly, with junior developers, we
don’t want them to learn at the begin-
ning of their careers that it’s right to
whine about working with legacy code
and that they should pass this approach
on to the next generation.Rewrite or Refactor?
TL;DR it depends. Many times I saw
fire in the eyes of programmers thrown
into a legacy project. It’s the kind of
look that says mentally they’re already
driving a bulldozer and they’re plan-
ning a new bright future: in the place
of that hut, they’re going to build a
skyscraper the people of Dubai would
be proud of. Of course, with the use of
your beloved language, libraries, etc. I
understand the temptation well. I used
to be a programmer who bites off more
than he can chew; way before hearing
what domain I would be working
with. Although rewriting the project
from scratch makes sense, it is worth
knowing what it may be connected
with. First, it is worth getting to know
the way the current code works.
A complete rewrite of the application
can make sense as long as you know the
system’s problems for users, and you
know what design decisions turned
out to be bad from the perspective of
time. Surely it is worth knowing the
current requirements (and how they
have changed in comparison to the
previous ones) and what are the devel-
opment plans for the future. With such
knowledge, you can prepare a system
that bypasses previous limitations and
is prepared for the future.
The most significant disadvantage
is the need to maintain two systems at
the same time, the old and the new one.
Even if the business agrees to go into
the service mode for the old version,
it means we do not add new features,
but support existing customers. There
will undoubtedly be serious bugs or
important customers who force adding
a new feature to the current version
before rewriting the project ends. All
this slows down your work.