Refactoring Messy to Testable Code in .NET (Part 3)
HTML-код
- Опубликовано: 17 окт 2020
- In this series, we'll work through refactoring a messy .NET Core MVC web application with a lot of procedural code and no tests. When we're done, we'll have a more testable, object-oriented, extensible application, complete with unit tests and static code analysis wired up with a continuous integration loop with GitHub Actions. We'll cover topics like inversion of control via dependency injection, replacing conditionals with polymorphism, factory methods, sending messages between small objects, unit testing, naming, and much more!
What is Legacy Code?
“Code without tests is bad code. It doesn’t matter how well-written it is; it doesn’t matter how pretty or object-oriented or well-encapsulated it is. With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don’t know if our code is getting better or worse.”
― Michael Feathers, Working Effectively with Legacy Code
Legacy code - code without tests - is everywhere. It is not unusual in practice to encounter entire applications with few or even no tests. It is perhaps just as common to find software with legacy tests that don't adequately test current software behavior.
As a professional software developer, you will inevitably work on code that is difficult to change and difficult to test. This will be because the original authors of the code (maybe even yourself) didn't understand how to write code that easy to change, didn't understand the importance of unit and integration testing, or perhaps didn't "have time" to write tests for code when it was originally written.
In this course, you'll clone a messy codebase and work step-by-step with me to get it back into shape - complete with tests, continuous integration, and static code analysis! We'll use concepts from object-oriented and functional programming to write cleaner, more testable, more modular code that is easy to change. This is much more than just "DRY" -we'll focus on concepts like:
Extensibility - we'll make it easier to implement new features
Loose coupling - we'll look at how "new is glue," "static cling," and side-effects lead to tightly-coupled software
Minimizing side effects - find out how writing more functional code can prevent unexpected behavior and decrease the chance you'll introduce bugs
Decreasing complexity - often the easiest code to write increases overall complexity - we'll look at how improving your ability to apply slightly advanced techniques can actually decrease the complexity of your application and make it much easier to reason about at different levels of abstraction
Improving naming - notoriously one of the most difficult tasks in software development - what do we call this thing?
Making smaller things - making smaller objects that inter-operate by sending and receiving messages make your codebase easier to maintain, organize, and reason about.
GitHub repo: github.com/productive-dev/ref...
More free and premium courses: courses.productivedev.com 
Наука
In this video, we start work on replacing conditional logic with polymorphism. We'll soon extract a factory method and use Task.FromResult, which is useful when implementing an interface that allows asynchronous implementations, but certain implementation run synchronously, as is the case in the extracted OrderProcessors in this section.
Excelent! Love you tutorials! Really excited for the next one!!!
Nice Job Wes .
Thanks Vic Jay! Good to hear from you. All the best
Great stuff as ever! I have seen code before that looks pretty innocuous but when you look inside it has a big print routine in the middle..
😀 Good to hear from you!
Is there any website with projects for refactoring?
Why did you create separate classes for each district?
I was wondering, what if we've 100s of districts?
In that case, the refactoring solution of having each class for each district for OrderProcessor would not be a feasible refactoring solution.
When you get time, Could you share your thoughts on this?