Global Day of Coderetreat

A day of deliberate practice and learning.

📆 Saturday, 2022-11-05
☑️ Mandatory registration
🧩 More details next slide

Looking forward to seeing you soon!

About

The Vienna software crafting community invites you to participate in our local event for the Global Day of Coderetreat.

On this day, we come together to learn from each other, practice pair programming & test-driven development and focus on design aspects related to decoupling.

If that sounds interesting to you, we are thrilled to have you join us!

Global Day of Coderetreat

Welcome to a day of deliberate practice and learning!

🛒🧾🛍️ 💡🤝🤓 🪢✂️🧵

Which Language? 💬

Spricht jemand nur Deutsch? Bitte melden.

Does anyone speak only English? Please report.

Big Thank you to Nagarro! 💗

Thank you very much for hosting us!

Dinner 🍽️

Who wants to join dinner?

Please raise your hand.

Is this your first Coderetreat? 🥇

Please raise your hand.

What is a Coderetreat? 🤔

A day of deliberate practice and learning.

Deliberate Practice and Learning?

Not about getting things done
Doing things differently
Try out new ideas
Do it right!

How does it work?

We work on the same problem repeatedly.
Try out different approaches.
Learn from each other.

Practice - reflect - improve! 🥳

Schedule 🕤

Time	Topic
08:20	Arrival & Breakfast
09:00	Welcome at Nagarro
09:10	Intro Coderetreat 👈
	Session 1 by Peter Kofler
	Session 2 by Patrick Scheibert & Katrin Heiderer
	Session 3 by Adam Zielinski
13:10	Lunch Break
	Session 4 by Claus Aichinger
	Session 5 by Roland Germ
	Final Retrospective
17:00	Closing

About us 👋

Facilitators in order of appearance.

Peter Kofler @codecopkofler
Katrin Heiderer & Patrick Scheibert
Adam Zielinski @adam0x5A
Claus Aichinger @clausaichinger
Roland Germ @rolgerm

What about you? 💐

Let’s get to know each other:

Who are you?
Why is it better to be here than elsewhere?
What will you contribute?

Form groups of three (with people you don’t know).

Code of Conduct 🤝

Be mindful of your peers.

Be respectful.

Questions?

Today’s Practice 🥷

Supermarket Receipt 🛒🧾🛍️

For a collection of items in the shopping cart

look up prices,
apply discounts,
compute total and
generate receipt.

More about the assignment in the first session.

Pair Programming 🤝

Roles:

🧭 Navigator Giving directions, looking ahead
🚗 Driver Manipulating the code, concerned with small details

Procedure:

Talk to each other
Switch roles every 5 minutes

Refactoring 🔧

Improve code but don’t change behavior
Don’t break interfaces

Test-driven Development 🧪

If you write new code, write a test first
If you change code, is it covered by tests?

Decoupled Design 🤔

What is design?

Why does it matter?

Today’s practice: strategies to decouple design!

How do we get there? 🤓

Revisit same problem repeatedly
Try different strategies to improve design

Questions?

Session 1

Focus: Familiarize yourself with the problem.

Facilitator: Peter Kofler @codecopkofler

Our Kata: Supermarket Pricing

Pricing goods at supermarkets

The supermarket has a catalogue with different products (rice, apples, etc.).
Each product has a price.
- Item Products have simple prices. E.g. a can of beans costs €1.65.
- Loose Weight Products have more complex prices. E.g. €1.99 per kilo.
The total price of the shopping cart is the sum of all the prices of the items.
Your receipt lists the items you’ve bought, the total price and discounts.
The supermarket runs special deals like
- Percent discount on item, e.g. 10% discount on rice, normal price €2.49 per bag. 20% discount on apples, normal price €1.99 per kilo.
- Buy two toothbrushes, get one free. Normal toothbrush is €0.99.
- X for Y discount, e.g. Five tubes of toothpaste for €7.49, normal price €1.79. Two boxes of cherry tomatoes for €0.99, normal price €0.69 per box.

Our Mode of Work: Pen and Paper

Before we start coding, let’s think:

Identify concepts.
How would we design such a system?
Maybe do a verb-noun analysis.
Make a sketch.
Which actions/events are there?
Be explicit.

Only work on requirements listed above!

Extra Challenge: Decoupled Design

Do we need to get data from somewhere?
Do we need to write/print/format data somewhere?
Which “concerns” are there? (If concern means anything to you.)
Which domains/subdomains are involved? (If domain means anything to you.)

Find a Partner! 👀

Deliberate Practice and Learning 🤓

Retrospective 🤔

Which parts are “different”?
Which components did you identify?
Are Stock and Shop the same domain? No? How do we handle it?

Enjoy the Break ☕

And be back in time.

Session 2

Focus: Familiarize yourself with the code (and face reality).

Facilitator: Patrick Scheibert, Katrin Heiderer

Existing Code :-(

The code is there, we want to improve it.

https://github.com/swkWien/SupermarketReceipt-Refactoring-Kata

Code Review, Refactoring, Pair-Programming

Read the code (“read by refactoring”)
Which design elements (aka classes) are there?
How are they connected? Which classes hold which data?
Which classes are doing what?
Compare with your diagrams from session 1.

Tips

Start with small IDE refactoring steps.
Rename the variables so they are more meaningful.
Extract methods to reduce complexity of the code.

Extra Challenges

One Level of Indentation

Each method cannot contain statements that require more than one level of indentation (conditional statements, loops, etc)

Short Methods

Limit the number of statements permitted for a function to 5 lines.

Find a Partner! 👀

Deliberate Practice and Learning 🤓

Retrospective 🤔

“I agree / Don’t agree”

Retrospective 🤔

Which refactorings did you do?
Which class or method names did you change?
What was your experience in the pairs with different languages?

Enjoy the Break ☕

And be back in time.

Session 3

Focus: Separation of concerns

Facilitator: Adam Zielinski @adam0x5A

Separation of concerns - Why? 🤔

“the only available technique for effective ordering of one’s thoughts, that I know of” (Dijkstra, 1974)

Reduce complex problems into a series of manageable layers and components.

More degrees of freedom (to introduce changes, reuse, deployment, …)

Separation of concerns - Design to make our life easier! 🥳

Reduce Coupling: Separate things that are different into separate classes.

Coupling is measured by the number of relations between the classes. That is, the coupling increases as the number of calls between classes increase or the amount of shared data is large.

Improve Cohesion: Put things that do the same thing together.

Functional, Sequential, Communicational, Procedural, Temporal, Logical, …

Separation of concerns - How? ⚙️

Identify “who is responsible for what?”

Hints:

Clarify responsibilities between Teller and ShoppingCart.
Separate view, formatting and logic.
What about Law of Demeter violations in ReceiptPrinter? (“only talk to friends”)

Extra Challenges

Use only keyboard shortcuts, no mouse 🐭

for navigation and refactoring

Visualize 📦

Visualize the coupling (e.g. Control / Data Coupling)

Find a Partner! 👀

Deliberate Practice and Learning 🤓

Retrospective 🤔

Which concerns could you identify?
Have you introduced Abstract Data Types (Interfaces)? If so, which?
How many tests would you have to alter?
Could you visualize the coupling of classes?

Enjoy Your Lunch! 🥗🌽🥬🥟🍛🧆

Session 4

Focus: Improve class design by applying principles

Facilitator: Claus Aichinger @clausaichinger

Requirements Change :-/

Feature requests:

Introduce special deals database
Support HTML receipts
Allow discounted bundles
…

What now? 🪢👀

Yes, decouplings sounds good. But… 🤔

How? 🤷

Apply principles!? 🪢✂️🧵

I’m not a great programmer; I’m just a good programmer with great habits.

Kent Beck in Refactoring: Improving the Design of Existing Code

Yes! Improve Class Design

Apply so called SOLID principles:

The Single Responsibility Principle (SRP)

A class should have one, and only one, reason to change.

A module [class] should be responsible to one, and only one, actor.

The Open Closed Principle (OCP)

You should be able to extend a classes behavior, without modifying it.

The Liskov Substitution Principle (LSP)

Derived classes must be substitutable for their base classes.

The Interface Segregation Principle (ISP)

Make fine grained interfaces that are client specific.

The Dependency Inversion Principle (DIP)

Depend on abstractions, not on concretions.

What does it mean? 🧐

For example:

SRP: Split up
OCP: Inject collaborators (dependencies) in constructor
DIP: Express collaborators through interfaces
ISP: Provide different interface depending on usage
…

Decouple using SOLID 🧩

And pave the way for new features…

Suggestion: SRP and `ShoppingCart`

Relates to previous session.

Suggestion: SRP and `ShoppingCart.handleOffers()`

Relates to feature request.

Suggestion: OCP & DIP and `SupermarketCatalog`

Relates to feature request.

Suggestion: OCP and `ReceiptPrinter`

Relates to feature request.

Find a Partner! 👀

Deliberate Practice and Learning 🤓

Retrospective 🤔

Did you focus on a feature? Which?
Did you focus on a class? Which?
Which SOLID principle did you apply?
How did “apply principle” influence your development?

Enjoy the Break ☕

And be back in time.

Session 5

Focus: Separating a Domain into Bounded Contexts

Facilitator: Roland Germ @rolgerm

Decoupling into functional Areas

Which grouping of the domain did you identify in the 1st session today?
How should we split a domain in functional areas?

Domain and Bounded Contexts

A Domain consists the whole model
Large models are divided into subdomains or bounded contexts driven by separating business needs
A bounded context is a projection of the problem space into the solution space
Code that combines two bounded contexts gets convoluted because it’s mixing two separate vocabularies together (“Martin Fowler”).

Bounded Contexts of the Supermarket Domain

Anti-Corruption-Layer - a clear boundary between bounded contexts

The journey from direct dependencies

To dependency inversion

Anti-Corruption-Layer

Multiple Anti-Corruption-Layer building a Hexagonal Architecture

Tips

Start by creating directories for the separate domains.
Decide which code belongs to a domain and move it to the right location (this includes moving methods/functions)
Create your anti-corruption-layers between the domains (start with the simplest).

Find a Partner! 👀

Deliberate Practice and Learning 🤓

Retrospective 🤔

Which domains did you create ?
Which dependencies do you have finally?
How did name the name the ports and adapters?
What constructs hindered you?
What do we achieve by applying a hexagonal architecture

Our retreat is coming to an end…

Final Retrospective 😉

What did you learn?
What did you enjoy?
What did surprise you?
What do you take away?