Book Image

Improving your C# Skills

By : Ovais Mehboob Ahmed Khan, John Callaway, Clayton Hunt, Rod Stephens
Book Image

Improving your C# Skills

By: Ovais Mehboob Ahmed Khan, John Callaway, Clayton Hunt, Rod Stephens

Overview of this book

This Learning Path shows you how to create high performing applications and solve programming challenges using a wide range of C# features. You’ll begin by learning how to identify the bottlenecks in writing programs, highlight common performance pitfalls, and apply strategies to detect and resolve these issues early. You'll also study the importance of micro-services architecture for building fast applications and implementing resiliency and security in .NET Core. Then, you'll study the importance of defining and testing boundaries, abstracting away third-party code, and working with different types of test double, such as spies, mocks, and fakes. In addition to describing programming trade-offs, this Learning Path will also help you build a useful toolkit of techniques, including value caching, statistical analysis, and geometric algorithms. This Learning Path includes content from the following Packt products: • C# 7 and .NET Core 2.0 High Performance by Ovais Mehboob Ahmed Khan • Practical Test-Driven Development using C# 7 by John Callaway, Clayton Hunt • The Modern C# Challenge by Rod Stephens
Table of Contents (26 chapters)
Title Page
Copyright and Credits
About Packt
What to Know Before Getting Started
Files and Directories
Advanced C# and .NET Features

What is legacy code?

Most of you have probably had to work on a dreaded legacy project. Working on that project is no fun; the code is a mess, and you want to find whoever wrote it and find out what they were thinking when they wrote it.

At some point in your career, you have been or will be that person to someone else. We all write code that we will not be proud of later. But why does the code get so bad? When does a project become legacy? Lastly, what can be done to prevent this?

Why does code go bad?

In short, the code goes bad because we are afraid to change it. Why would the code not changing cause it to be bad? You would hope that, when the code was written, it was the best code that the developer was capable of producing at the time. So, that code should have been good, right? This is a complicated answer but assume, for the moment, that the code was something to be proud of when it was originally written. That still begs the question, how did it go bad?

The answer is staring you in the...