Working With Legacy Rails Apps

Transcript

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