Common information about all trainings
If haven’t done so yet, please read the Trainings page that contains general information about all of my trainings . It contains common background, core ideas the main concepts that I use throughout all of my trainings. They are presented very differently in each training but share common code quality principles.
Goal of training
Learn to tackle with technical debt on daily basis. Feel the thrill of refactoring and make it a habit to maintain code readability and extendibility continuously.
This hands-on workshop teaches how to retain code quality by refactoring in the smallest possible steps so it becomes everyday practice. This allow to continue with much more complex refactorings when needed. Your team will possess refactoring skills and its members will gain inspirations on how to introduce code quality care habits into daily / weekly practices of their teams.
We start with technical skills and go through awareness of your attitude that is always reflected in outcome code quality. Regardless if you want it or not this attitude is always reflected by your’s and your team’s actions or lack of them. Awareness is the first step to change it.
More about training - might be TLDR 🙂
Refactoring is very well known in theory. It looks like everyone has heard about it. But do we know how to approach it? Isn’t it often a theory followed by an idea to re-write given part of code because we are afraid to touch given code any longer?
During the workshop we go carefully through the concept of Pyramid of Refactoring :
Pyramid of refactoring Wide
  • Simplifying the logic of algorithms
  • Extracting smaller methods
  • Extracting smaller classes
  • Notifying emerging design patterns
  • Cleaning up the architecture
The training is mainly focused on working with code using automated refactoring-features that are built into IntelliJ or Eclipse. The source code is based on Java language. The trainer does all the refactorings live in small steps what allows the attendees to follow it with the same changes on their laptops. Remaining 25% of the training is dedicated to motivation part, how to make refactoring a daily habit, some slides and discussions.
Please note also that this is a training mainly about refactoring – not necessary about the design. Different people / teams might prefer different designs whereas the goal of this training is to show how easy / fast we can change the low level design and keep the design emergent according to our architectural decisions and needs.
Plan of training
Part 1
  • Getting to know the “everyday” piece of code which you can quickly understand and “extend”
  • Showing how quickly this “fast development” by copy-paste approach will reduce code readability
  • Playing with code refactorings – from the simplest transformations as extracting variables, methods, extracting parameters from these methods followed by moving these methods into existing or new classes and ending up with hiding classes behind their abstractions.
  • Presentation of the Refactoring Pyramid, how this concept was used in the order of the above applied refactorings.
  • Application of SOLID principles as a basis for dividing architecture into smaller parts
Part 2
  • Getting familiar with the extended code from part 1 where new functionality was added but no refactorings has been performed at all
  • Presentation of requirement for additional functionality to be added
  • Quick brainstorming that we can do it quickly with decreasing readability of the code
  • Performing the “extraction of extension points” as a result of “refactoring journey” using the concept of the Refactoring Pyramid
  • Providing new functionality as a new implementation of the “extension point” using TDD
This is a very extensive training and based on the experience the proposed approach is make it is as 2 days of 4 hours. This lets the developers focus on other daily activities in the remaining part of the day. On demand it can also be conducted as one (very extensive) day or (fully occupied) 2 days.
Target audience
Regular developers, although senior developers claim that they’ve learned lots of new things / ideas and shared them with fellow developers.