$30 off During Our Annual Pro Sale. View Details »

Working With Legacy Rails Apps

Working With Legacy Rails Apps

Ahmed Omran

July 10, 2015

More Decks by Ahmed Omran

Other Decks in Programming


  1. Working With Legacy Rails Apps @this_ahmed

  2. Working With Legacy Rails Apps @this_ahmed

  3. legacy code • untested code (Michael C. Feathers) • code

    someone else wrote (old gems, outsourcing, maintainers left) • difficult to work with • risky to change • but serves a useful function
  4. googling legacy code …

  5. every project has legacy code?

  6. None
  7. • learning & experimenting • ambitious applications • big project,

    developer churn, hiring outside help • bad code … even with the best of intentions • “Technical debt”
  8. None
  9. –Robert C. Martin “Even the most disciplined development team, knowing

    the best principles, using the best patterns, and following the best practices will create messes from time to time.”
  10. in the face of legacy code you can …

  11. None
  12. or…

  13. None
  14. Useful techniques

  15. Rebuild Refactor

  16. –Robert C. Martin “…taking a tangled, opaque, convoluted system and

    slowly, gradually, piece by piece, step by step, turning it into a simple, nicely structured, well-designed system.”
  17. Boy Scout Rule Clean up around you work area. Small

    fixes; small refractors.
  18. cover and modify • add unit test • test passes

    • modify code • test passes
  19. use mock objects to break dependencies

  20. None
  21. mock dependencies

  22. break complicated dependencies with seams

  23. None
  24. seam => put in method + stub

  25. first step to later refactor

  26. i don’t understand this code…

  27. Ask someone

  28. code archeology

  29. code archeology git blame / Github

  30. code archeology search code for context git blame / Github

  31. code archeology project management ticket git blame / Github search

    code for context
  32. code archeology git blame / Github project management ticket commit

    message search code for context
  33. review • boy scout rule • cover and modify •

    break dependencies with mocks and seams • understand code with archeology
  34. some parting thoughts

  35. unit test

  36. None
  37. None
  38. • code review • small git branches • add lots

    of context in pull request / commit message