While computer science education, books, tutorials, and online courses all focus on creating new projects from scratch, the reality is that almost all development jobs you’ll have will center around understanding, maintaining, and expanding pre-existing code that may not meet your current standards.

This pre-existing code is referred to as legacy code. You almost always inherit some amount of legacy code when joining a new project. This can be a large amount of code for pre-existing projects or a smaller set of libraries your code must work with.

There are many different definitions of the term legacy code. One that stands out to me from my readings is Michael C. Feather’s definition, in Working Effectively with Legacy Code, that legacy code is code without tests.

While I like Michael’s definition and believe testing is critically important, as we’ll see in Part 2 of this book, I personally define legacy...

So, how do you know whether your code has issues?

How do you know whether food has spoiled, clothing needs to be washed, or a diaper needs changing? It turns out that it just smells bad.

There are some metrics about what constitutes “good” and “bad” code, and we’ll explore them in Chapter 12: Code Analysis in Visual Studio and Chapter 16: Adopting Code Standards. Smelly code can be subjective to some degree or another. A developer who wrote a section of code or frequently modifies that portion of code may find the code to be more tolerable than a developer encountering the code for the first time.

While not all pieces of technical debt are identical, it turns out that many pieces of legacy code share a set of common symptoms.

These symptoms are commonly referred to as “code smells” and can include the following:

• It’s difficult to understand what it does or why it does it
• You or people...

Refactoring is one of those words that doesn’t make a lot of sense to newer programmers, but here’s a simple definition:

Refactoring is the act of changing the shape or form of code without changing its functionality or behavior.

There are two key concepts here:

• The first concept is that refactoring is an effort to improve the maintainability of existing code. Sometimes, restructuring means introducing a new variable, method, or class. Other times, refactoring simply changes how individual lines of code are arranged or which language features are used. Even something as simple as renaming a variable could be considered a small act of refactoring.
• The second concept in this definition is that refactoring does not alter the behavior of the code in question. Refactoring is a structural change done to bring some piece of technical merit without altering the existing behavior of your code. If a method typically returned a certain value...

The rest of this book will follow code examples from an airline called Cloudy Skies Airlines, or Cloudy Skies for short. Through these examples, we should be able to see how technical debt and refactoring can apply to a “real” organization and its software.

Note

Cloudy Skies is a fictitious airline company created for this book for teaching purposes only. Any resemblance to any real company is purely coincidental. Additionally, I have never worked in aviation, so the code examples presented in the book are likely significantly different from actual software systems used in the industry.

Cloudy Skies is an airline that’s been around for the past 50 years and currently operates a little over 500 jets in its fleet, serving around 70 cities in its region.

Twenty years ago, the airline made a major move and started replacing its aging software systems with custom in-house applications built by its development team...

Legacy code is an unavoidable byproduct of the forces of time and constant change that are present in software development projects. This legacy code becomes a breeding ground for technical debt, which threatens our productivity as developers and the quality of our software.

While technical debt can arise due to a number of reasons, refactoring is the cure. Refactoring reworks existing code into a more maintainable and less risky form, reducing our technical debt and helping us control our legacy code.

The more you understand the causes and effects of technical debt in your code, the better you’ll find yourself equipped to explain technical debt to others in your organization, advocate for refactoring, and avoid things that cause your code to decline in effectiveness over time.

In the next chapter, we’ll explore refactoring in more depth by walking through a set of targeted changes to improve a piece of sample code from the Cloudy Skies Airlines codebase...

1. What is the difference between technical debt and legacy code?
2. What are some causes of technical debt?
3. What are some of the effects of technical debt?
4. Is it possible to avoid technical debt?
5. Is it possible to get to a point where your code cannot be refactored further?

You can find more information about technical debt, legacy code, and refactoring at the following URLs:

• Defining Technical Debt: https://killalldefects.com/2019/12/23/defining-technical-debt/
• Identify Technical Debt: https://learn.microsoft.com/en-us/training/modules/identify-technical-debt/
• The True Cost of Technical Debt: https://killalldefects.com/2019/11/09/the-true-cost-of-technical-debt/
• Code refactoring: https://en.wikipedia.org/wiki/Code_refactoring