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
Contributors
Preface
8
What to Know Before Getting Started
17
Files and Directories
18
Advanced C# and .NET Features
Index

Dealing with legacy problems


We have been discussing all the issues with legacy code. Now it is time to tackle solving those issues. The first thing we must do is bring sanity to the targeted legacy code, and then we can begin testing and eventually fix the code and bring it back from death.

Safe refactoring

The term refactoring is often used incorrectly. When refactoring, you are merely changing the structure of the code. If the logic and/or signature of the code in question changes, then this does not qualify as refactoring. This is a change; most likely a breaking change.

If I'm changing the structure of the code (refactoring), then I don't ever change its behavior at the same time. If I'm changing the interface by which some logic is invoked, I never change the logic itself at the same time.

– Kent Beck

A safe refactoring is one that is guaranteed to not accidentally break the code. Other changes that aren't intended to actually change the behavior of the code but could do it accidentally...