I have been delivering workshops about refactoring for a few years. These are Effective Refactoring and Refactoring to Design Patterns. In my spare time I am preparing next ones, but only such ones where refactoring subject is the key part. Examples then are : Working with Legacy Code and Test Driven Development.

These trainings are always composed of two parts (that are mixed) that are related to our approach / motivation and skills. This is because in order to use your skills you need to be motivated / willing to do so – which is often hard, especially when it comes to convincing / teaching the others..

My current offer consists of two trainings. Each of them can be led using IntelliJ or Eclipse environment. Anyway the team needs to decide which are all of the attendees will use because otherwise due to differences in their functionalities developers using IntelliJ would need to wait for the others and some refactorings are not automated (hopefully yet) in Eclipse. Moreover the shortcuts for automated refactorings are different in these environments and repeating them twice throughout the day takes time.

  1. Effective Refactoring
    Refactoring is very well known in theory. It looks like everyone has heard about it. But do we know how to approach i? Isn’t it often a theory followed by an idea to re-write given part of code because we don’t like it any longer?This hands-on training shows how to handle refactoring in the smallest possible steps, make it everyday practice and grow your refactoring skills. It’s goal is also to motivate people to refactor their code and share their knowledge within their teams continuously.

    We will go carefully through the Pyramid of Refactorings :

    • understand the flow
    • extract smaller methods
    • extract smaller classes
    • notify emerging design patterns from relations between classes
    • tidy up the architecture (packages)


    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 about refactoring – not about the design. Different people / teams might prefer different designs whereas the goal of this training is to show how easy / fast we can turn the design upside-down according to our architectural decisions and needs.

    Part 1

    1. Start with a small code that is easy to catch up with
    2. Understand how easy to extend it using copy-paste approach but make it harder to maintain at the same time
    3. Divide the design into smaller pieces using Pyramid of Refactoring approach
    4. Learn lots of build-in IDE refactorings
    5. Talk about SOLID design that is the basement of Pyramid of Refactoring


    Part 2

    1. Start with that same code from part 1 where new requirements were implemented using copy-paste approach without any refactorings (ugh…)
    2. Describe additional requirements that needs to be implemented
    3. Understand how much more difficult it is now to continue using copy-paste approach and continue to make the code less and less maintainable at the same time
    4. Extract the “extension” points using the Pyramid of Refactoring
    5. Implement the new functionality as and pluggable parts using small amount of 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.

    Level : junior and regular developers, although senior developers claim that they’ve learned lots of new things / ideas and shared them with fellow developers.

    You will learn how to start from the smallest possible refactorings and end up with emerging design patterns (which is second part of this training :-).

  2. Refactoring to Patterns

    Patterns are everywhere around us. They are things which proved to be good and common. Why? Because of their values like effectiveness, reusability and beauty.In 2015 Ralph Johnson (one of the authors of “Design Patterns : Elements of Reusable Software Architecture” book) during his talk “21 years of design patterns” told us “We could have done better, but I think we’ve done pretty well”.Usually the patterns are not visible to be necessary at the beginning. But once the codebase grows we begin to miss them and think like “if I only had a strategy / factory / state patterns here instead of the net of if-else / switch statements…”In this training I’d like to show you some examples of refactorings into design patterns. In order to cover lots of patterns the samples are already prepared (cleaned up) so that we can move forward with code refactoring towards them.

    The ones covered are

    • (Fluent) Builder
    • Chain of Responsibility
    • Proxy
    • Composite
    • Factory Method
    • Abstract Factory
    • Interpreter
    • Template
    • Bridge
    • State

    Therefore please note that this is a continuation of “Effective Refactoring” and is based on an assumption that initial clean-up of your codebase – like simplified conditions, smaller methods and classes in your code – has already happened. Such a clean-up is a must-have step as otherwise you will not be able to notice emerging design patterns out of the mess of your legacy code.

    The attendees of this training will experience how design patterns might simplify but also de-simplify the design. How they can solve the problems at current state of design and introduce next issues within the design if the approach to the design is followed with copy-paste approach without further refactorings / thoughts.

    Although design patterns give us lots of benefits we should not start with introducing them from scratch. This is because design patterns make our code simpler only behind certain point of complexity. Before this point patterns introduce their own additional complexity.

    This is a very extensive training. 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. It can also be conducted as one (very extensive) day.

    Level : junior and regular developers, although senior developers claim that they’ve learned lots of new things / ideas and shared them with fellow developers.

Each training can be led as one day or two days training – depending on the content. Anyway in case of Refactoring to Patterns 2 days are strongly suggested.