Merciless Refactorer
This work is licensed under a Creative Commons Attribution 4.0 International License by Gregor Riegler.
Layout: © 2023. MIT License.
Here I am working on the Expense Report Refactoring Kata. I like it because of its small size. For me, the kata is about making focused refactorings. In this episode I have already completed the challenge of the kata, and refactor the code even further. I am tackling primitive obsession. It is the final video in the expense report series.
Here I am working on the Expense Report Refactoring Kata. I like it because of its small size. For me, the kata is about making focused refactorings. In this episode I test drive the change and add the new Lunch Type. After that I continue refactoring the code, as there are lots of things I can still improve.
Here I am working on the Expense Report Refactoring Kata. I like it because of its small size. For me, the kata is about making focused refactorings. In this episode I start to refactor the code. My refactoring is very focused so I only make those changes that make the task of adding a new ExpenseType easier.
Here I am working on the Expense Report Refactoring Kata. I like it because of its small size. For me, the kata is about making focused refactorings. In this episode I finish testing the code using ApprovalTests for Java.
I am starting to work on the Expense Report Refactoring Kata. I like it because of its small size. For me, the kata is about making focused refactorings. In this video I will walk you over the code, and create a first test skeleton using ApprovalTests for Java.
I am applying the Dependency Inversion Principle on authorization code to make it more testable.
In this video i am finishing my refactoring on the coffee machine kata. Silently, without talking, just refactoring. It is quite long and occasionally hard to track. Just Pause whenever you need to.
I like to use Subclass to Test when i need to refactor first to isolate a proper Seam. It helps break a hard dependency and get the legacy code under test. This pattern is sometimes also called Test Specific Subclass.
The Humble Object Pattern is used to separate code that is hard to test from code that is easy to test. We typically apply this at the boundary where we interact with code we don’t own. For example a framework. We make our own code testable by moving the code that interacts with the third party code to a humble object. It does so little we don’t have to test it.
When you need to make changes to legacy code it is often a good idea to start with some refactoring. But to be able to refactor, we first need to put it under test. And this can be quite challenging, especially when the code contains hard dependencies. In this video i am demonstrating a way to break a time dependency and make the code testable again.
A derived field is similar to a cache in the sense that you have to actively maintain its state throughout everything that is happening in your domain. So it is similarly complex to cache invalidation. We can replace it with a query method, and get rid of the complication. This doesn’t mean we can’t add caching to the query method later. We can easily add this cross-cutting concern later on using memoization or a decorator pattern if we really need it.
I am doing a little bit of comprehension refactoring on the model of the coffee machine. When doing comprehension refactoring, we study the code and keep our eyes open for design smells. We start renaming things and move stuff around so the code becomes more reasonable for us.
I am refactoring the Coffee Machine Cli App that i tested in the last episode towards Model View Controller Pattern.
Adding characterization tests to a legacy java code command line application. Running into the legacy code dilemma because of dependencies to the System global.
I found the code thanks to Ted Young, check out his quality coding twitch stream.
Where the code originates from: stackexchange post
Recommended book: Working Effectively With Legacy Code
Recommended talk: Michael Feathers - the deep synergy between testability and good design.
The 3rd party lib i used for Characterization Testing: Seamer.
Post about Preparatory Refactoring.
Moving a cross cutting concern to a decorator can improve flexibility and at the same time reduce complexity of the subject.
The lift up conditional refactoring is useful for complex and deeply nested conditionals, where related parts are scattered all over the place. I am using the Gilded Rose Kata, which is a perfect example, as it consists of a really complex conditional.
A conditional, like a switch statement can sometimes be fraudulent. It appears to be a nice and simple solution when it is in fact hiding and provoking duplication. By refactoring to polymorphism we adhere to the ‘Tell Don’t Ask’ principle and get rid of the duplicated parts.
In a split phase refactoring, we split a tangled piece of code that does more than one thing into distinguished phases that only do a single thing. As a result we can more easily and independently change each of the resulting phases.
A value object is a reusable, immutable object that does not only encapsulate a primitive value, but also its behaviour. Identifying and extracting those value objects improve the cohesion in our code, and avoids duplication. Suppose i created a new component that consumed an already existing value object, i would be able to reuse the values methods instead of implementing duplicated code by accident.