Gilded Rose Refactoring Kata by: Dmitry Kandalov

Gilded Rose code kata is an exercise designed to practice your refactoring skills. It simulates a legacy project in which you need to improve the code so you can add a new feature. In this live coding session, I will use the Kotlin version of the kata to show how a sequence of incremental improvements can make a difference, taking program design to a better and more functional place. You will see a few refactoring heuristics, IntelliJ tips and tricks, and design emerging from seemingly chaotic code.

Talk by: Dmitry Kandalov

#kotlinconf'23 #Kotlin #intellij #KotlinConf

[AntonArhipov]

Dmitry is awesome! Superb demonstration!

[IsuruKusumal]

I was there, i witnessned his black magic live 🤩

[MSK-Academy]

My favorite programming language Kotlin

[rastislavsvoboda]

coool !
I don't know Kotlin, but I enjoyed it!

[jonaskoelker]

Interesting talk. He uses a different approach than me, and ends up with a different structure.

My final structure is more similar to that of GPT-3:

if (item has type 1) { do all the things for item type 1 } else if (item has type 2) { ... } else { do all the generic item things }.

Having seen the alternative, I still like my structure better. Here's an argument I made up on the spot: it seems to me that we might have different item types and update rules in the future. Just in case `sell_in` and `quality` need to be updated in an interestingly coupled way, I don't want those two parts separated. That would force me to recompute the old `sell_in` when deciding the `quality` update for a new item type.

My approach for getting there was also different:

At the start of the loop, add "if (item has type 1) { do all the things for item type 1; continue }; <the rest of the loop goes here>". I would simultaneously reorganize a bit of the loop for clarity. Additionally, once I had implemented the item-type-1 rules to my satisfaction, I would know that it could never show up in the rest of the loop, so I could simplify it. This allowed the structure of the remaining cases to become more apparent. Then, I would expand this to "if (item has type 1) { do all the things for item type 1; continue } else if (item has type 2) { do all the things for item type 2; continue }; <the rest of the loop goes here>", and so on until my if-elseif-else branches covered all cases.

That is, I would basically treat the old code as impossible to salvage and rewrite it from scratch. Well, I kept a copy of the old code around, to test that mine produced identical outputs in all relevant scenarios.

For code snippets this size, I think both approaches can be fruitful—depending on personal temperament, tools available and self-confidence.