Dev Approaches - Legacy Code

[dearshrewdwit]

Short workshop to introduce working with legacy code

https://github.com/boolean-uk/tdd-todolist-legacy

Teacher notes

• mantra: we write code for other people, not ourselves.
  • accordingly code should be linted, and formatted according to given style guide.
  • reading and understanding legacy code is a skill: practice practice practice. The purpose of this exercise is primarily on the process of reading and extending simple legacy code.

Bobs Bagels Legacy

• choose 3 student implementations (mixed quality -> allocate accordingly) Fork repositories. Students, in pairs, apply their process to continue work on Bobs Bagels requirements and extensions.
• Highlight two main refactoring strategies: Extract Method, Extract Class.
• There might be missing specs - add those in before extending. Test suite should give confidence.
• Allow for meaningful work before reflecting with the cohort on the learnings from this => two afternoons minimum.

[dearshrewdwit]

Expected Learnings (elicit)

• Extending other people's code is hard! Why?
  • Low quality code is cognitively expensive
  • Low quality means: hard to read and understand code/domain model/specs
  • Overly complex, lots of operations happening, long methods, classes. Unconventional formatting.
• How do we make this easier?
  • lint code
  • well-written specs, useful domain model.
  • modularity: single responsibility, cohesion, loose coupling, DRY

[dearshrewdwit]

Bobs Bagels - Legacy

standard-simple: https://github.com/boolean-uk/js-bobs-bagels-lilac (Nico) standard: https://github.com/boolean-uk/js-bobs-bagels-burgundy (Kiran) extension1: https://github.com/boolean-uk/js-bobs-bagels-turquoise (BenC) extension1-ish: https://github.com/boolean-uk/js-bobs-bagels-gold (WillC) extension2: https://github.com/boolean-uk/js-bobs-bagels-beige (Paul)

Student Instructions

• install project locally: fork, clone, install dependencies
• Open a PR, give it a name in the format [cohort]-[name1]-[name2], eg: c4-alice-bob
• Read specs, domain model if exists.
• read source code.
• create domain model if not exists
• Add specs if missing
• Refactor code if opportunity present (extract method, extract class)
• plan next requirement
• RGR

[dearshrewdwit]

1. Prepare pairs within the cohort.
2. Assign to the pair a repository that matches their confidence (it's ok if multiple pairs fork the same repository)
   • demonstrate forking, cloning, and starting a requirement
3. Pairs open a PR straightaway
4. Follow the same development process