Moving away from legacy code with BDD

Moving away from legacy code

with BDD

BDD Evangelist

BDD Practice Manager @Inviqa

Creator of Behat, Mink, PhpSpec2, Prophecy

Contributor to Symfony2, Composer

@everzet

This talk is about

• Solving purely technical “TCIAM” problem using behavioural business analysis and discovery process

• Building a delivery strategy on the idea of the change appreciation

• Real-life experience

This talk is not about

• Greenfield projects

• Maintenance-mode projects

• Solutions for everyone

• How to write code

Legacy projects

How most developers see their next project

My next project

My next project

His actual next project

Agile, TDD, BDD, General QA, etc…

// TODO: refactor this later

Is it really that bad?

If the project can afford at least one full-time specialist on a payroll that whines how horrible this project is, then surely it did something right.

// TODO: refactor this later

// TODO: refactor this later

// TODO: refactor this later

This world is full of brilliant projects that nobody wants to whine about. Sadly, it’s often simply because there’s no one left to pay for that.

The truth is: You deliver value!

Just not as effectively as you could

• Great value + Awful code = Great product today

• Great value + Great code = Great product tomorrow

• No value + Any kind of code= Awful product anytime

• Great value + Awful code = Great product today

• Great value + Great code = Great product tomorrow

• No value + Any kind of code= Awful product anytime

// TODO: refactor this later

Agile, TDD, BDD, General QA, etc…

How?

Three popular options

1. Rewrite an entire application using “the right way”

2. Do technical refactoring

3. Do business-oriented rewrite using “BDD pipeline”

#1: Full Rewrite

#1: Full Rewrite

• Scrum / Kanban

• TDD / BDD / DDD / Other XP goodness

• New everything

• Mirroring functionality

#1: Income

6 Months later…

#1: Almost there…

#1: Full Rewrite

Just spaghetti, please: 4 man years

Full London meal (TDD, BDD, Agile, QA): ??? man years

#2: Technical Refactoring

#2: Technical Refactoring

• Blackbox testing

• New routing

• New templating system

• Migration of model layer (MySQL -> Mongo)

• Whatever else that is easy to replace

#2: Income

6 Months later…

#2: Ta-da!!!

– Your client. (most likely)

“Exactly what did you do here?”

#3: BDD PIPELINEAKA Business-Focused rewrite

Why do legacy projects suck?

Cost

Time

Because of the cost of change

… Of change where?

Why do applications change?

Welcome to the wonderland

of Behaviour Driven Development

Questionnaire

1. Where is this project going?

2. Which features are going to change?

3. How are they going to change?

4. How to support that change?

“BDD Pipeline”

1. Where is this project going?

2. Which features are going to change?

3. How are they going to change?

4. How to support that change?

• Impact Mapping

• Business Prioritisation

• Example (3 Amigos) Workshop

• BDD layers

1. Where is this project going?

Impact Mapping

– Gojko Adzic

“Impact mapping is a strategic planning technique that prevents organisations from getting lost

while building products and delivering projects, by clearly communicating assumptions, helping teams align their activities with overall business objectives and make better roadmap decisions.”

Four levels of Impact Map

1. Why? are we doing all this (rewrite)? What is the goal we’re trying to achieve?

2. Who? will be impacted by it?

3. How? can they help us to achieve the goal?

4. What? can we do to support them?

MVP

Product Backlog

In order to buy more products As a customer I need to have a product autocompletion in the search field

2. Which features are going to change?

Business Prioritisation

In order to maintain my shopping history As a site visitor I need to be able to register on this site

In order to maintain my shopping history As a site visitor I need to be able to register on this site

benefit

actor

SELECT s.* FROM backlog as s ORDER BY s.role, s.benefit LIMIT 25

3. How are these features going to change?Example (3 Amigos) workshops

Three layers of a User-Story

• Business rule(s)

• Communication

• Acceptance criteria

Three layers of a User-Story

• Business rule(s) == Acceptance criteria

• Communication

Three layers of a User-Story

• Business rule(s) == Acceptance criteria

• Communication == Examples

Three layers of a User-Story

• Business rule(s)

• Communication == Examples == Acceptance criteria

In order to keep track of stock As a store owner I want to add items back to stock when they are returned

Feature: Returned items go back to stock

Scenario: Refunded items should be returned to stock

In order to keep track of stock As a store owner I want to add items back to stock when they are returned

Feature: Returned items go back to stock

Scenario: Replaced items should be returned to stock

Scenario: Refunded items should be returned to stock

In order to keep track of stock As a store owner I want to add items back to stock when they are returned

Feature: Returned items go back to stock

Scenario: ...

Scenario: Replaced items should be returned to stock

Scenario: Refunded items should be returned to stock

In order to keep track of stock As a store owner I want to add items back to stock when they are returned

Feature: Returned items go back to stock

Scenario: ...

Scenario: ...

Scenario: ...

Scenario: ...

Scenario: ...

Scenario: Replaced items should be returned to stock

Scenario: Refunded items should be returned to stock

In order to keep track of stock As a store owner I want to add items back to stock when they are returned

Feature: Returned items go back to stock

Given a customer previously bought a black sweater from me And I currently have three black sweaters left in stock When he returns the sweater for a refund Then I should have four black sweaters in stock

Scenario: Refunded items should be returned to stock

In order to keep track of stock As a store owner I want to add items back to stock when they are returned

Feature: Returned items go back to stock

4. How to make it work?Delivery

Given a customer previously bought a black sweater from me And I currently have three black sweaters left in stock When he returns the sweater for a refund Then I should have four black sweaters in stock

Scenario: Refunded items should be returned to stock

In order to keep track of stock As a store owner I want to add items back to stock when they are returned

Feature: Returned items go back to stock

Architectural approaches

1. The Inside job

2. The Bridge

Architectural approach#1 The Inside job

Step#1: Identify change area

Step#1: Identify old logic

Step#2: Discuss old logic

1. What should this thing do

2. What if it suddenly stops doing it?

3. How would you know if it doesn't work?

4. How would you know if it does?

Step#3: Prepare for A change

1. Cover old behaviour in an end-to-end fashion

2. Make sure that scenarios/tests are green

3. Refactor code to make the upcoming change easier

4. Make scenarios/tests green

Step#4: Make a change

1. Automate new scenarios

2. Make scenarios green by applying BDD loops

Stories

Examples

Describe

ImplementDesign

Architectural approach#2 The bridge

Legacy system

Infrastructure

[GET] /products

Legacy system

Infrastructure

[GET] /products

[GET] /products/123

Legacy system

Infrastructure

[GET] /products

[GET] /products/123

New system

Legacy system

Infrastructure

[GET] /products

[GET] /products/123

New system

New system

Step#0: Prepare for any change

1. Prepare the application infrastructure for bridging

a. Share sessions

b. Share data

2. Prepare the server infrastructure for bridging

Step#1: Make a change

1. Automate new scenarios

2. Make scenarios green by applying BDD loops

#3: Income

6 months later…

#3: Same ashtrays, better car

Stop dreaming of a greater code

Find a way to deliver a greater value

We do that for clientsAnd coach / train others how to do it

http:// .com

Thank you!

@everzet