LargeRefactorings
From SPA Wiki
Workshop "Large Refactorings", MartinLippert, StefanRoock, OT 2003
Participants
- PeterMarks
- ErikGroeneveld
- PeterHammond
- AlanFrancis
- RayFarmer
- PascalVanCauwenberghe
- PeterSchrier
- MarcEvers
- WillemvandenEnde
- MattStephenson
- MartinLippert
- StefanRoock
Results of workshop
Please do not change the results. Discussion of the results takes place at LargeRefactoringsDiscussion.
Best Experiences with Refactorings
- Took a call centre app. in Smalltalk and refactored the difficult to follow code while enhancing it for web. Results in much easier maintenance because we also have auto tests for the code now.
- Code becomes simpler, more intentionally and smaller by lots of small refactorings (small steps, basic refactorings)
- Turning up-side-down the complete design of an object-relational mapping tool (took a weekend)
- Refactorings force me to write tests
- Refactoring flow: Refactoring in many small steps with more
- repair defects not by hunting bugs, but improving structure
- find classes where I didn't expect them
- You may refactor now - No need, it's already done.
- Bringing in sensible specialization
- great tool support for Java
- Ending up with a RDB layer from refactoring my unit tests
- Removing repetition in JavaScript producing successively better code
- roman numerals: collapsing many special cases into "base" (5, 10, 50, 100)
- using IntelliJ Idea
Worst Experiences with Refactorings
- Having to hide our refactoring work because our customers don't understand. They think they are paying twice for same function.
- Refactoring without tests (no unit tests, no acceptance tests): never sure if a refactoring really preserves behaviour
- Breaking the product by going in without tests
- Large refactorings get stuck. That makes system structure worse.
- "Bug Hell" (just before refactoring): restructuring non-compiling code for a month (thousands OK lines)
- Are we allowed to refactor? No!
- Removing one simple dependency between two classes, and leave all tests failing, without any clue on how to fix that (took 20 minutes)
- Skipped refactorings because of time pressure.
- I had to stop in the middle of medium sized refactoring. Did not write any thing down to memorize it. Too long a time to pick it up again and having a failing system. Had to throw away quite some things.
- Large unstructured program. Modified many times - impossible to change - started again.
- Moving method causes many tests to fail.
- Refactoring multi-threaded command processor (4 days)
Questions / Problems
- What are the most effective "selling points" to help my customers know that refactoring on any scale is a good thing?
- What large refactorings do others select
- Communicating large refactorings to others in team
- How to plan a big refactoring spread over a couple of iterations
- How to foresee the effects of single steps during a large refactoring
- How ca I keep my other team members involved in the refactoring that takes weeks or months to complete (e.g. turn parts of the system up-side down)
- the conditions where large refactorings are neccessary
- How to do it - when the original legacy code is so bad
- large refactorings within a team
- How to manage the focus on such large refactorings, so they get done.
- How to manage the consequences of a significant large refactoring
- Do tests make large refactorings easier or more difficult
- How to do one step at a time ... and execute at each step
Categories of questions / problems (ordered by votes)
- Getting Lost
- Communication of Change
- Business Case
- Small Steps
- Breaking Tests
Characteristics of large refactorings
- gets worse before it get's better
- benefit(large) > sum of(benefit(small))
- system is broken for a long time
- affects structure / architecture
- affects team / steps must be integrated
- needs explanation
- can't remember all steps
- Large Refactoring vs. Large Collection of Small Refactorings (Long Refactoring)
Behaviours for refactorings
- check in
- small: check in asap
- large: delay check in
- tests
- small: change tests first
- large: spike solutions, ignore tests
- planning
- small: just start
- large: plan and publish steps
- reflection
- small: reflect after refactoring
- large: reflect often
- commitment
- small: just do it
- large: get agreement from team
"Getting Lost": What to do
- throw stuff away / undo
- take a break
- change pair
- zoom out
- keep goal in mind
- keep looking at the goal
- don't hack it into a working state
- don't keep going regardless
"Communication of Change": What to do
- Standup Meetings
- draw a vision and make it visible
- report progress
- indentify scope beforehand
- track plan
- communicate new idiom
