Refactoring fest
Abstract: Introduce the participants to real world refactoring by taking an open source project and refactoring it. This session will help people understand
1. How to identify code smells?
2. How to eliminate the code smells by applying refactoring techniques explained in Martin Fowler‘s book?
3. How to refactor in absence of unit and functional tests [Working effectively with legacy code base]?
4. How to refactor to patterns?
5. Internals of the open source project chosen to refactor
Type of session: Hands on session.
Prerequisites:
1. Good Object Orient programming skills
2. Experience with Unit testing using the xUnit framework. Experience with mock objects can be helpful.
3. Pair programming. The participants should be willing to pair program. They will need to pair and do the real thing 😉
4. The group decides any one open source project in the language of their choice.
5. Laptops or machines should be setup with a decent IDE and the source code. Each pair should have at least one functional laptop/machine. Make sure the code compiles and works on each machine.
6. Projector to which all the machines can be connected one after other.
Nice to have:
1. Network connectivity
2. A server with version control and continuous integration server setup.
If this approach is chosen, you need to make sure that each pair checks out the source code from this version control repository.
Selection criteria for the open source project:
1. Functionality of the project is pretty simple and straight forward to understand. Ex. Log4j, simple wiki, etc
2. The project is being used extensively on the team. Will help them understand it better.
3. Has an average sized code base. Too huge or too small code base will not be effective.
4. Should be easy to setup and test on any machine.
Execution:
1. Plan for at least five, 2 hours sessions.
2. In the first session,
2.a. First 60 mins: the coach explains/shows different code smells and briefly explains the associated refactoring techniques.
2.b. Next 30 mins: the coach gives a high level over view of the open source project‘s design
2.c. Last 30 mins, the team breaks into pairs and each pair picks up a module/package of the open source project. The rest of the time is spent in understanding the functionality of the module/package in individual pairs.
3. From the second sessions onwards:
3.a. The team splits into pairs, picks one or more classes from the module/package, understand what it does, writes unit tests around it. Once they have sufficient passing unit tests, they start identifying code smells and refactoring them. In some cases, sufficient unit tests might not be required to do simple refactoring like extract method, rename variable, etc. Sometimes internally restructuring the code, can help us understand it better. Hence you need to constantly wear the understanding, unit testing and refactoring hat.
3.b. At the end of 30 mins, the team stops refactoring. Sequentially every team connects to a central project and demonstrates their accomplishment to the rest of the group. The next 30 mins are spent discussing each team‘s refactorings.
3.c. The pairs swap partners so that each team gets a new member and one old member continues on the selected module/package. And they continue refactoring.
3.d. At the end of 30 mins we have another demo and then end of session.
3.e. If we have the version control and continuous server setup then people check in their source code and make sure the build passes.
These sessions can continue as long as the team is interested and they think they are learning something new. At the end of these sessions, the team would have made several improvements to the open source project. These improvements can then be submitted back to the open source community. Having a version control and continuous integration server can really simplify this.
I ran these sessions at ThoughtWorks and will be running them at the Agile Philly user group shortly.
