Software

Reengineering

Dr. Ruqia Bibi

1
 Understanding the
challenges of legacy
projects

2
Introduction
 The average developer spends much more time working with existing code
than writing new code.

 The vast majority of developers have to deal with legacy projects in some
shape or form.

 Secondly, remember that there’s always hope for revitalizing a legacy

project, no matter how far gone it may first appear.

3
What is a Legacy System ?

“legacy”
A sum of money, or a specified article, given to another
by will; anything handed down by an ancestor or
predecessor. — Oxford English Dictionary

Typical problems with legacy systems:

• original developers not available
• outdated development methods used
A legacy system is a
• extensive patches and modifications
piece of software that:
• you have inherited, and have been made
• is valuable to you. • missing or outdated documentation

 so, further evolution and development may be prohibitively expensive

Definition of a legacy project
 Note that we’re talking about a project here, not just a codebase.

 As developers, we tend to focus on the code, but a project encompasses

many other aspects, including

 Build tools and scripts

 Dependencies on other systems
 The infrastructure on which the software runs
 Project documentation
 Methods of communication, such as between developers, or between
developers and stakeholders

5
Characteristics of Legacy
Systems
1. OLD
• Usually a project needs to exist for a few years before it gains
enough entropy to become really difficult to maintain.
• In that time, it will also go through a number of generations of
maintainers.
• With each of these handoffs, knowledge about the original
design of the system and the intentions of the previous
maintainer is also lost.
Characteristics of Legacy
Systems
2. LARGE
• It goes without saying that the larger the project is, the more
difficult it is to maintain.
• There is more code to understand, a larger number of existing
bugs (if we assume a constant defect rate in software, more code
= more bugs), and a higher probability of a new change causing
a regression, because there is more existing code that it can
potentially affect.
• The size of a project also affects decisions about how the project
is maintained.
• Large projects are difficult and risky to replace, so they are more
likely to live on and become legacy.
Characteristics of Legacy
Systems
3. INHERITED
• As is implied by the common meaning of the word legacy, these
projects are usually inherited from a previous developer or team.
• In other words, the people who originally wrote the code and
those who now maintain it are not the same individuals, and they
may even be separated by several intermediate generations of
developers.
• This means that the current maintainers have no way of knowing
why the code works the way it does, and they’re often forced to
guess the intentions and tacit design assumptions of the people
who wrote it.
Characteristics of Legacy
Systems
4. POORLY DOCUMENTED
• Given that the project spans multiple generations of
developers, it would seem that keeping accurate and
thorough documentation is essential to its long-term
survival.
• Unfortunately, if there’s one thing that developers
enjoy less than writing documentation, it’s keeping that
documentation up to date.
Legacy code

 The most important part of any software project, especially for

an engineer, is the code itself.

10
1.Untested, untestable code
 A good test suite can function as the de facto documentation for a
project.

 In fact, tests can even be more useful than documentation,

because they’re more likely to be kept in sync with the actual
behavior of the system.

 Unfortunately, many legacy projects have almost no tests.

 Not only this, but the projects are usually written without testing
in mind,

11
2.Inflexible code
 A common problem with legacy code is that implementing new features or
changes to existing behavior is extremely difficult.

 Imagine your application defines two types of users: Admins and Normal
users.

 Admins are allowed to do anything, whereas the actions of Normal

users are restricted.

 The authorization checks are implemented simply as if statements, spread

throughout the codebase.

 It’s a large and complex application, so there are a few hundred of these
checks in total, each one looking like the following.

12
Inflexible code

13
Inflexible code
 One day you’re asked to add a new user type called Power User.

 These users can do more than Normal users but are not as powerful as
Admins.

 So for every action that Power Users are allowed to perform, you’ll have to
search through the codebase, find the corresponding if statement, and
update it to look like this.

14
Inflexible code

15
3.Code encumbered by
technical debt
Every developer is occasionally guilty of writing code that they know isn’t


perfect, but is good enough for now.

 Every temporary or hacky solution reduces the overall quality of the project
and makes future work more difficult.

 Debt is often used as a metaphor for this accumulation of quality issues.

 Implementing a quick-fix solution is analogous to taking out a loan, at some

point this loan must be paid back.

 Until you repay the loan by refactoring and cleaning up the code, you’ll be
burdened with interest payments, meaning a codebase that’s more difficult
to work with.
 If you take out too many loans without paying them back, eventually the
interest payments will catch up with you, and useful work will grind to a halt.

16
Legacy infrastructure

Just looking at the code doesn’t show you the whole picture.

Most software depends on an collection of tools and infrastructure in

order to run, and the quality of these tools can also have a dramatic
effect on a team’s productivity.

17
1.Development environment
 Setting up a legacy project often involves a combination of:

 Downloading, installing, and learning how to run whatever arcane

build tool the project uses

 Running the mysterious and unmaintained scripts you found in the

project’s /bin folder

 Taking a large number of manual steps, listed on an invariably out-

of-date wiki page

18
2. Outdated dependencies
 Nearly any software project has some dependencies on third-party
software.

 For example, web application

Keeping up with the latest versions of all dependencies is a

constant effort,

19
Outdated dependencies

 Upgrades often provide performance improvements and bug fixes,

and sometimes critical security patches.

 While you shouldn’t upgrade dependencies just for the sake of it,
upgrading is usually a Good Thing.

20
3.Heterogeneous
environments
 Developers run the software on their local machines.

 They deploy it to a test environment for automatic and manual testing.

 It is deployed to a staging environment that mimics production as closely as

possible.

 It is released and deployed to the production environment (or, in the case of

packaged software, it’s shipped to the customer).

21
Legacy culture
 Fear of change:
 Many legacy projects are so complex and poorly documented that
even the teams charged with maintaining them don’t understand everything
about them. For example,

 Which features are no longer in use and are thus safe to delete?
 Which bugs are safe to fix?
 Which users need to be consulted before making changes

 Because of this lack of information, many teams come to respect the status
quo as the safest option, and become fearful of making any unnecessary
changes to the software.

22
Legacy culture
 Knowledge silos:

 The Biggest Problem while maintaining software is Lack of knowledge.

 Domain information about the users’ requirements and the functional specifications
 Project-specific technical information about the software’s design, architecture,
 and internals
 General technical knowledge such as efficient algorithms, advanced language features,
handy coding tricks, and useful libraries

 Each individual developer becomes a metaphorical silo of information, with all their
valuable knowledge sitting untapped inside their heads instead of being shared for the
benefit of the whole team.

23
24
Finding your starting
point

25
Introduction

 After previous lecture, you should have a clear idea of what legacy software
is and why you’d want to improve it.

 Now we’ll look at how to formulate a plan for improvement and how to
measure your progress once the plan is in place

26
Overcoming feelings of fear and
frustration

 Two emotions that are often provoked by legacy

 code:

 Fear

 Frustration.

27
Fear
 Fear of code is often fear of the unknown. In a large codebase,
there are likely large bindings of code that you don’t understand
well.

 It’s this unexplored territory that scares you the most, because:

 you don’t know what the code is doing,

 how it’s doing it,

 how it’s linked to the parts you’re more familiar with.

28
Fear (Example)
 Let’s say you’re tasked with maintaining your company’s employee time-
tracking system, codenamed TimeTrack.

 It’s a legacy Java application that was developed in-house years ago,
mostly by just one developer who has now left the company.

 Unfortunately he left little in the way of tests or documentation, and the only
useful document you could find was the architecture diagram in figure .

29
Fear (Example)

30
Fear (Example)
 So far your only maintenance has been to add a few small features to the
web UI, so

 you’re reasonably familiar with the UI component, but you’ve hardly

touched the other components.

 You’d like to clean up some of the code you found in the Core component,
but you know that the payroll batches also depend on Core, and you’re
scared that you might break those.

31
Fear (Solution)
 The best way to overcome this fear of the unknown is simply to dive into the
code and start playing around with it.

 Open up the Core project in your IDE and try renaming methods, moving
methods between classes, introducing new interfaces, adding
comments—basically anything you can think of that makes the code cleaner
and more readable.

 This process is known as exploratory refactoring. It has a couple of

benefits.

32
BENEFITS OF EXPLORATORY
REFACTORING
 Exploratory refactoring increases your understanding of the code.

 The more you explore, the more you understand (i.e. Less Fear).

 Exploratory refactoring improves the readability of the code. Provide noticeable

improvements to the readability of the code at the level of individual classes and
methods. (not to achieve deep, revolutionary changes at the architectural
level.)

 When performing exploratory refactoring, always remember that you have

strong allies you can rely on to protect you.

 The version control system

 IDE
 Compiler
 Other developers

33
Frustration

 Working with legacy code can sometimes be very frustrating. Even the
simplest fix can involve touching 20 different instances of the same copy-
pasted code.

 Adding a new feature can take days when it should really take minutes, and
trying to follow the logic of excessively complex code can be a real
mental strain.

 This frustration can often lead to one of two outcomes: loss of

motivation or desperate measures.

34
Frustration (Solution)

 Refactoring is a never-ending process, so we need data that can help us

make decisions based on a given snapshot of the software, both now and in
the future.

 To show the quality of the software and how that quality is changing over
time.

 To decide what our next refactoring target should be.

 This may be a part of the code that is quantitatively worse than others

 or it may be code whose refactoring provides a lot of value to the team.

35
Gathering useful data about your
software
We want to gather metrics about legacy software in order to help us
answer the following questions:

What state is the code in to start with? Is it really in as bad shape as

you think?

What should be your next target for refactoring at any given time?

How much progress are you making with your refactoring?

36
Gathering useful data about your
software

First we need to decide what to measure.

This depends largely on the particular software, but the simple

answer is measure everything you can.

37
1. Bugs and coding standard
violations
Static analysis tools can analyze a codebase and detect possible bugs or
poorly written code.

 Static analysis involves looking through the code (either the human-
readable source code or the machine-readable compiled code) and
flagging any pieces of code that match a predefined set of patterns or
rules.

 FindBugs may flag any code that fails to close an Input Stream that it has
opened, because this may result in a resource leak and should thus be
considered a bug.

 A style-checking tool such as Checkstyle searches for code that violates a

given set of style rules. It may flag any code that’s incorrectly indented or is
missing a Javadoc comment.

38
2. Performance
 One goal of your refactoring may be to improve the performance of a legacy
system.

 If that’s the case, you’ll need to measure that performance.

 If you wanted to test the performance of the Audit component, you could
start with the following test:

1. Start the system in a known state.

2. Feed it 1 million lines of dummy log data.

3. Time how long it takes to process the data and generate an audit report.

4. Shut down the system and clean up.

39
2. Performance

40
MONITORING PERFORMANCE IN
PRODUCTION
 If your software is a web application, it’s easy to collect performance
data from the production system.

 Any decent web server will be able to output the processing time of
every request to a log file. You could write a simple script to
aggregate this data to calculate percentile response times per hour,
per day, and so on.

 One excellent tool that can be used to measure and visualize the
performance of production systems is Kibana.

 Kibana is an open source visualization tool mainly used to analyze a

large volume of logs in the form of line graph, bar graph, pie charts,
heatmaps etc.

41
 PMD (static analysis tool)
 Another popular static analysis tool for Java is PMD.

 Unlike FindBugs, PMD works by analyzing Java source code rather than
the compiled bytecode.

 For example, PMD can check for readability issues, such as

inconsistent use of braces, or code cleanliness issues such as duplicate
import statements.

47
 CYCLOMATIC COMPLEXITY

 Cyclomatic complexityis a count of the number of different paths

your program can take inside a given method.

 Usually it’s defined as the sum of the number of if statements,

loops, case statements, and catch statements in the method, plus 1
for the method itself.

 In general, the higher the cyclomatic complexity, the more difficult a

method is to read and maintain.

48
Summary

Any Questions?

50