Before we begin . . .

Go to the back of the room and  . . . 

 

Write down the biggest problem you've had with existing code: Put it on the left <=

Write down what you'd like to learn about dealing with existing code: Put it on the right =>

Scratch Refactoring

Scratch Refactoring to Understand: Unearthing your Domain

@ie_ddd

https://www.dddireland.org

 

 

Sponsored by: 

Legal case management

  1. The difficulties of existing code
  2. What is Scratch Refactoring?
  3. Tips and Tricks
  4. Scratch Refactoring Session
  5. Group Discussion
  6. Networking

Workshop Structure

Existing Code

The difficulties it creates

  • Hard to understand
  • Expensive to change
  • Change is risky
  • Hard to test

How we explore code (naive)

  1. Look at code
  2. Figure out what change you need to make
  3. Figure out where you need to change
  4. Make the change
  5. Verify it

How we explore code (actual)

  1. Look at code
  2. Panic
  3. Figure out what change you need to make
  4. Guess at where you need to change
  5. Hack it in
  6. Attempt to verify it

We must accept that we don't understand

We must Explore

Take a piece of code and refactor the hell out of it without trying to keep it working.

 

The goal is to explore the code and gain understanding, not to fix it (at least not yet)

Scratch Refactoring

To change something you must first understand it.

 

If you don't understand a piece of code, then how can you change it safely?

Why Scratch Refactor?

The Exploration Feedback Loop

(Complex quadrant of Cynefin Framework)

When to do it

When the code makes you react like this:

  1. Extract private methods: Lean of auto refactoring tools
  2. Describe the behaviour not the implementation
  3. Rename variables, try out different names and concepts
  4. Move code around and isolate logic
  5. Put like with like
  6. Focus on the code that matters, ignore and isolate the rest
  7. Do it in pairs/mobs
  8. Take notes of discoveries and concepts
  9. Scrap it all and start again, see where you end up

Scratch Refactoring Tips

Remove noise by spotting patterns:

  • Ports and Adapters
  • Factories
  • Repositories
  • ValueObjects/Entities

Unearthing your Domain

Applying DDD while Scratch Refactoring

  • Think in layers: Domain, Application, Infrastructure
  • Isolate conditionals into private methods, name them
  • Factories, Repositories, Services, Value Objects, Entities
    • Extract into methods, maybe go as far as classes
    • Give them names, iterate on those names
  • ​Separate noise from signal: What it's doing vs how it's doing it

Unearthing your Domain

Figuring out what problem the code is solving

The Workshop

Scratch Refactoring Session

  • Find a messy piece of code and scratch refactor it
  • Choose one or two techniques and try them out
  • Do it alone or in pairs
  • If you don't have a laptop/code, pair up with someone
  • Go mad, try out ideas and see where you get!
  • No wrong answers, you can always start again

Techniques

  1. Rename variables for clarity
  2. Put like with like, isolate concepts
  3. Private method extraction
  4. Isolate infra logic, give it a name
  5. Extract methods/classes
    1. Extract a value object
    2. Extract a factory
    3. Extract a service
    4. Extract a repository
  6. Just explore and see where you get to

Next meetup

End of November

Topic: Scratch Refactoring Continued

 

Dogpatch-guest: flyforawifi

Scratching Refactoring: Unearthing your domain

By Barry O' Sullivan

Scratching Refactoring: Unearthing your domain

Have you ever worked with a piece of code and thought "WTH is this thing even doing?!"? Something so messy and convoluted that your brain just gives up? Of course you have; dealing with this kind of code is just part of the job, but it's a part that we don't discuss anywhere near enough. That's why we're holding a workshop on how to deal with this kind of code, via a technique known as Scratch Refactoring. Scratch Refactoring is a way to explore potential designs in messy code. In this workshop we'll explore how it can be applied to unearth domain concepts hidden in your application. We'll discuss practical real world techniques, which we will then apply to code we've brought in ourselves. That's right, we'll try out Scratch Refactoring then and there! DDD practitioners will be on hand to help. Afterwards we'll review our results and discuss what we've discovered.

  • 67
Loading comments...

More from Barry O' Sullivan