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

How most developers see
their next project

My next
project
His actual next
project

Agile, TDD, BDD,
General QA, etc…
// TODO: refactor this
later

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.

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

// TODO: refactor this
later
Agile, TDD, BDD,
General QA, etc…

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
• Scrum / Kanban
• TDD / BDD / DDD / Other XP goodness
• New everything
• Mirroring functionality

#1: Full Rewrite
Just spaghetti, please: 4 man years
Full London meal (TDD, BDD, Agile, QA): ??? man years

#2: Technical Refactoring
• Blackbox testing
• New routing
• New templating system
• Migration of model layer (MySQL -> Mongo)
• Whatever else that is easy to replace

– Your client. (most likely)
“Exactly what did you do here?”

#3: BDD PIPELINE
AKA Business-Focused rewrite

Cost
Time
Because of the
cost of 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?

Moving away from legacy code with BDD

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.beneﬁt
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

• Business rule(s) == Acceptance criteria
• Communication

• Business rule(s) == Acceptance criteria
• Communication == Examples

• 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
As a store owner

Scenario: Replaced items should be returned to stock
As a store owner

Scenario: ...
As a store owner

Scenario: ...
Scenario: ...
Scenario: ...
Scenario: ...
Scenario: ...
As a store owner

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
As a store owner

4. How to make it work?
Delivery

Architectural approaches
1. The Inside job
2. The Bridge

Architectural approach
#1 The Inside job

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
Implement
Design

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

Stop dreaming of a greater code
Find a way to deliver a greater value

We do that for clients
And coach / train others how to do it
http:// .com

Moving away from legacy code with BDD

More Related Content

Viewers also liked (9)

Similar to Moving away from legacy code with BDD (20)

Recently uploaded (20)

Moving away from legacy code with BDD