YouTube recommended me a two-part video series that was fun to watch and gave me a few lightbulb thoughts.
Table of contents
Part 1: preparations
YouTube recommended me Nick Chapsas's video (part 1) about refactoring some .NET code. It was great.
In the first part of the two-part video series, Nick makes the code testable by extracting its dependencies and injecting them back via constructor injection. This way the dependencies can be mocked in unit tests.
Then he creates unit tests for the code before doing any refactoring. Otherwise it would be too easy to accidentally modify the logic of the code.
Part 2: refactorings
In the part 2 video, Nick does the actual refactoring. Three things struck in my mind.
Renaming method parameters can cause backwards incompatibility in C#
One method parameter has a typo in its name. It would be tempting to rename it, but it would be a breaking change to the consumers of the code (warranting a major version increment) because C# supports named arguments. That's a good point that I would have missed.
When are interfaces needed?
Nick creates interfaces for the extracted dependencies to make them mockable, expect for one class. That class doesn't need mocking, so it doesn't necessarily need an interface.
Using tuples instead of creating simple classes
One method needs to return two values. You could create a simple class for the return value, but Nick uses a tuple, skipping the need for creating that simple class.