Help! My Legacy Application is Unmaintainable!

3,363 views

Published on

It's nice to work on Green Fields projects. But most of us aren't that lucky! Most organisations have large legacy code bases to maintain. And the legacy applications, ugly as they are, are often what generates the revenue!

But legacy code bases are not easy to work with. Adding new features, or even fixing bugs, is slow and fraught with danger. Unexpected regressions are commonplace. Long testing cycles is the norm.

In this talk we will look at some strategies that can enable you to add new features to legacy systems faster and more reliably. We will examine where the hold-ups typically are, and what We will learn how to write cost-effective automated regression tests suites, and how to use unit testing as a way to document your legacy code base for future work, and improve its quality along the way!

Published in: Technology

Help! My Legacy Application is Unmaintainable!

  1. 1. HELP! My Legacy Application is Unmaintainable! Reducing the cost of change in legacy code bases
  2. 2. Consulta nt   Trainer   Mentor   Author   Speaker   Coder John Fer guson S mar t
  3. 3. Legacy applications are difficult to maintain
  4. 4. Legacy applications generate revenue
  5. 5. What is a legacy application? Old code base?
  6. 6. What is a legacy application? Outdated technology
  7. 7. What is a legacy application? “Legacy code is code without tests”! ! - Michael Feathers
  8. 8. But what is wrong with legacy code? Nothing…if you don’t need to change it much
  9. 9. Legacy code is bad when… …it is hard to add new features
  10. 10. Legacy code is bad when… …changes risk introducing regressions
  11. 11. Legacy code is bad when… …poor coding style and/or lack of documentation makes the code hard to understand
  12. 12. Legacy code is bad when… …there are no automated tests
  13. 13. Legacy code is bad when… …it prevents you from delivering as quickly as you would like
  14. 14. Why not just rewrite it all?
  15. 15. Over  &me,  new  features  get   harder  and  harder  to  add Total cost to maintain the legacy application Cumulated effort to add new features Cost  of  not  rewri&ng Time
  16. 16. What do we really want? We need to be able to make the changes we need to make faster and more reliably
  17. 17. So how can we get changes out faster? Build a safety net Document the specifications
  18. 18. Build a safety net
  19. 19. Characterisation Test! ! A means to describe (characterise) the actual behaviour of an existing piece of software, and therefore protect existing behaviour of legacy code against unintended changes. ! Term coined by Michael Feathers
  20. 20. Broad, high level automated acceptance tests Application
  21. 21. To write good automated tests do not write tests
  22. 22. Write a user’s manual instead… …but automate it
  23. 23. Automate user journeys
  24. 24. Organise your requirements Browse the pr o duct catalog View pro duct details Search for pro ducts
  25. 25. Organise your requirements Browse the pr o duct catalog View pro duct details Search for pro ducts
  26. 26. Organise your requirements Browse the pr o duct catalog View pro duct details Search for pro ducts
  27. 27. Illustrate behaviour using examples
  28. 28. Document your business rules
  29. 29. Document your business rules
  30. 30. Good automated acceptance tests have layers Make them maintainable Keep them tidy Use layers!
  31. 31. Good automated acceptance tests have layers Make them maintainable Business  Rules Business  Flow Page/Component   interac&ons Page/Component   details
  32. 32. Start with high-level requirements
  33. 33. Drill down into more detailed requirements
  34. 34. Illustrate a requirement with tests
  35. 35. Documenting the specifications
  36. 36. A question of style Spock context["When cumulating Frequent Flyer points"] = () => { it["should earn points for each flight"] = () => { member.earnStatusPoints(100); member.earnStatusPoints(50); member.getStatusPoints().should_be(150); }; ! it["should get upgrade when enough points are earned"] = () => { member.earnStatusPoints(00); ! member.getStatus().should_be(Status.Silver); }; }; NSpec } }
  37. 37. A question of style JUnit
  38. 38. Adding new features TDD/BDD outposts in the wilderness
  39. 39. Discussion Time!
  40. 40. References BDD In Action - Manning http://thucydides.info http://www.wakaleo.com

×