back to Program
Refactoring: keeping software malleable
- organiser: DuncanPierce & IvanMoore
- session duration: 120 minutes
- session type: interactive tutorial/discussion
- intended audience: Anyone who wants to improve how they work with code. Participants do not need any previous experience of refactoring. Some experience of Java will be useful, but is not essential.
- presentation language: English
Note: You can bring your own laptop or use the computers provided by the organisers. Java 1.4 and an IDE that supports refactoring recommended. Examples will be given with Eclipse 3
Session description:
Most software gets new requirements over time. The accumulated changes
often stress the original design in unanticipated ways. When this
happens, the software often gets more and more difficult to work with:
development slows down, or more bugs appear. Sometimes it becomes so
difficult to add new functionality or prevent new bugs creeping in that
it seems easier to give up and rewrite the system from scratch.
This can be avoided by refactoring.
Refactoring breathes new life into code by changing the way it is
written without changing what it does, keeping the code malleable and
ready to accept change. It works in small, easy steps, and requires no
big investment.
This tutorial introduces and explains refactoring in a hands-on
tutorial. After this tutorial, attendees will be able to refactor
mercilessly to keep their code maintainable, ready for new
functionality.
This is based on the TDD tutorial format developed by Ivan, in which we
work slowly through an example with the audience and discuss what is
happening, what the next step should be, and so on. Most of the
learning comes from open discussion and demystification of the
refactoring process.
We hope this will eventually become a companion to the TDD tutorial.
Attendees will learn how to:
- make code more readable
- make code easier to change
- make the domain model more apparent
We will start with some code (not very good code) and a good automated
test suite.
After we have talked briefly about what the code does (in conjunction
with the tests)
we will look at a change we need to make to it, and explore with the
participants
why this change cannot be made easily with the code as it is.
Then we will begin to refactor. We identify a pressing but small
problem that is
holding us back, and proceed to solve it by a simple refactoring, which
the
participants also perform on their laptops. We expect that at the start
there will
be much discussion about the value of such small changes, and that the
participants
will initially struggle to see how small refactorings can make a big
improvement
in the code.
As we proceed, we will make the participants more responsible for
identifying problems
and suggesting refactorings, using simple guidelines like looking for
duplication.
We will encourage participants to work separately from the presenters
to come up
with their own refactorings, which we will all discuss. In this way,
participants will
learn how to create and apply their own refactoring steps.
At the end, if there is time, we will run a comparison of the original
and final
code so that participants can see how far we have come, even though the
steps were
small.
We expect to learn more about how simple refactoring can be through
interaction with
the attendees. In the past (on the TDD tutorial) we have found that
many minds coming
at a fairly simple problem from afresh yielded important insights for
us about how
far we can go in simplifying our approach to the problem.
back to Program
|
