Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Moving away from legacy code with BDD

1,202 views

Published on

Greenfield projects are awesome – you can develop highest quality application using best practices on the market. But what if your bread actually is Legacy projects? Does it mean that you need to descend into darkness of QA absence? Does it mean that you can’t use Agile or modern communication practices like BDD?

Published in: Technology

Moving away from legacy code with BDD

  1. 1. Moving away from legacy code with BDD
  2. 2. BDD Evangelist BDD Practice Manager @Inviqa Creator of Behat, Mink, PhpSpec2, Prophecy Contributor to Symfony2, Composer @everzet
  3. 3. 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
  4. 4. This talk is not about • Greenfield projects • Maintenance-mode projects • Solutions for everyone • How to write code
  5. 5. Legacy projects
  6. 6. How most developers see their next project
  7. 7. My next project
  8. 8. My next project His actual next project
  9. 9. Agile, TDD, BDD, General QA, etc… // TODO: refactor this later
  10. 10. Is it really that bad?
  11. 11. 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.
  12. 12. // TODO: refactor this later
  13. 13. // TODO: refactor this later
  14. 14. // TODO: refactor this later
  15. 15. 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.
  16. 16. The truth is: You deliver value! Just not as effectively as you could
  17. 17. • Great value + Awful code = Great product today • Great value + Great code = Great product tomorrow • No value + Any kind of code= Awful product anytime
  18. 18. • Great value + Awful code = Great product today • Great value + Great code = Great product tomorrow • No value + Any kind of code= Awful product anytime
  19. 19. // TODO: refactor this later Agile, TDD, BDD, General QA, etc…
  20. 20. How?
  21. 21. Three popular options 1. Rewrite an entire application using “the right way” 2. Do technical refactoring 3. Do business-oriented rewrite using “BDD pipeline”
  22. 22. #1: Full Rewrite
  23. 23. #1: Full Rewrite • Scrum / Kanban • TDD / BDD / DDD / Other XP goodness • New everything • Mirroring functionality
  24. 24. #1: Income
  25. 25. 6 Months later…
  26. 26. #1: Almost there…
  27. 27. #1: Full Rewrite Just spaghetti, please: 4 man years Full London meal (TDD, BDD, Agile, QA): ??? man years
  28. 28. #2: Technical Refactoring
  29. 29. #2: Technical Refactoring • Blackbox testing • New routing • New templating system • Migration of model layer (MySQL -> Mongo) • Whatever else that is easy to replace
  30. 30. #2: Income
  31. 31. 6 Months later…
  32. 32. #2: Ta-da!!!
  33. 33. – Your client. (most likely) “Exactly what did you do here?”
  34. 34. #3: BDD PIPELINE AKA Business-Focused rewrite
  35. 35. Why do legacy projects suck?
  36. 36. Cost Time Because of the cost of change
  37. 37. … Of change where?
  38. 38. Why do applications change?
  39. 39. Welcome to the wonderland of Behaviour Driven Development
  40. 40. 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?
  41. 41. “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
  42. 42. 1. Where is this project going? Impact Mapping
  43. 43. – 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.”
  44. 44. 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?
  45. 45. MVP
  46. 46. Product Backlog
  47. 47. In order to buy more products As a customer I need to have a product autocompletion in the search field
  48. 48. 2. Which features are going to change? Business Prioritisation
  49. 49. In order to maintain my shopping history As a site visitor I need to be able to register on this site
  50. 50. In order to maintain my shopping history As a site visitor I need to be able to register on this site benefit actor
  51. 51. SELECT s.* FROM backlog as s ORDER BY s.role, s.benefit LIMIT 25
  52. 52. 3. How are these features going to change? Example (3 Amigos) workshops
  53. 53. Three layers of a User-Story • Business rule(s) • Communication • Acceptance criteria
  54. 54. Three layers of a User-Story • Business rule(s) == Acceptance criteria • Communication
  55. 55. Three layers of a User-Story • Business rule(s) == Acceptance criteria • Communication == Examples
  56. 56. Three layers of a User-Story • Business rule(s) • Communication == Examples == Acceptance criteria
  57. 57. 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
  58. 58. 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
  59. 59. 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
  60. 60. 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
  61. 61. 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
  62. 62. 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
  63. 63. 4. How to make it work? Delivery
  64. 64. 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
  65. 65. Architectural approaches 1. The Inside job 2. The Bridge
  66. 66. Architectural approach #1 The Inside job
  67. 67. Step#1: Identify change area
  68. 68. Step#1: Identify old logic
  69. 69. 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?
  70. 70. 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
  71. 71. Step#4: Make a change 1. Automate new scenarios 2. Make scenarios green by applying BDD loops
  72. 72. Stories Examples Describe Implement Design
  73. 73. Architectural approach #2 The bridge
  74. 74. Legacy system Infrastructure [GET] /products
  75. 75. Legacy system Infrastructure [GET] /products [GET] /products/123
  76. 76. Legacy system Infrastructure [GET] /products [GET] /products/123 New system
  77. 77. Legacy system Infrastructure [GET] /products [GET] /products/123 New system New system
  78. 78. 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
  79. 79. Step#1: Make a change 1. Automate new scenarios 2. Make scenarios green by applying BDD loops
  80. 80. #3: Income
  81. 81. 6 months later…
  82. 82. #3: Same ashtrays, better car
  83. 83. Stop dreaming of a greater code Find a way to deliver a greater value
  84. 84. We do that for clients And coach / train others how to do it http:// .com
  85. 85. Thank you! @everzet

×