Wlodek Krakowski
Włodek Krakowski is a team leader and independent technical trainer. Also a developer if the time allows. His main interest is taking care of delivering valued software from different perspectives. These are how people take care of quality of code, how people work together towards providing business value, how people help to grow each other and how people are managed. Currently he works as IT Team Leader in Kraków, Poland and delivers technical / refactoring trainings at www.refactoring.pl.
Poker Hands – Refactoring into Chain of Responsibility
Poker Hands are are put into sequential order and the player who holds the highest one wins. Let’s make fun of it then and perform some refactoring of code that identifies what poker figure given player holds. We will transform a set of nested if-else statements into a nice chain of responsibility classes (Straight Flush, Four of a Kind, Full House, …) . This way the chain of classes put into sequential order will figure out the score given player holds. Proxy design patterns will come into the picture as well. All I can promise during this refactoring workshop is definitely no bluffing – just pure focus on code transformations. BTW : Did you know that real poker players are bluffing very rarely…? Prerequisite : become acquainted with poker rules if you haven’t played it so far, as business perspective and understanding existing code is the initial step for any refactoring. And don’t forget to install IntelliJ IDE – our master refactoring tool!
Please download the following sources prior to attending the Master Class: https://github.com/wlodekkr/chain-of-responsibility
Pyramid of Refactoring
Everyone has heard about test pyramid… and refactoring pyramid is its twin. Using Pyramid of testing we can set up the tests coverage of the existing functionality reaching given level (UI, modules, packages, classes, methods). This allows us to have a look at corresponding pyramid of refactoring and figure out what kind of refactorings can be performed safely. We start from the bottom of refactoring pyramid (simpler conditions, smaller methods) and climb up towards the highest level that is covered by tests.