Computer Science · 12th Grade

Active learning ideas

Refactoring and Code Quality

Active learning works for refactoring because students must experience the pain of messy code firsthand to recognize the value of structured design. When they struggle to read or extend poorly written code, the motivation to refactor becomes immediate and personal, not abstract.

• Common Core State Standards
• CSTA: 3B-AP-15
• CSTA: 3B-AP-21

• 15–50 min
• Pairs → Whole Class
• 4 activities

Activity 01

• Collaborative Problem-Solving
• 30 min · Small Groups

Code Critique: Smell Identification Gallery Walk

Print five code snippets on large paper and post them around the room. Each snippet has two or three distinct code smells (long method, magic numbers, duplicate logic, poor naming, deep nesting). Groups rotate every five minutes, identify the smells with sticky notes, and propose a refactoring. The debrief compares group choices and discusses cases where multiple refactorings are defensible.

Justify the importance of refactoring in the long-term maintainability of software.

Facilitation Tip

During Code Critique: Smell Identification Gallery Walk, circulate and ask students to explain each smell in their own words to reinforce understanding.

What to look for

Present students with a short code snippet containing 2-3 common code smells. Ask them to identify each smell by name and briefly explain why it is problematic. For example: 'Identify the code smell in lines 5-10 and explain why it needs refactoring.'

• Apply
• Analyze
• Evaluate
• Create
• Relationship Skills
• Decision-Making
• Self-Management

Activity 02

• Collaborative Problem-Solving
• 50 min · Pairs

Pair Refactoring Lab: Before and After

Provide a working but poorly structured 80-line function. Pairs write tests first to confirm the current behavior, then refactor the code by applying at least three named techniques. They run tests after each change to confirm nothing broke. Pairs present their refactored version and explain each decision.

Identify common 'code smells' that indicate a need for refactoring.

Facilitation Tip

During Pair Refactoring Lab: Before and After, remind students to run tests after every small change to build disciplined habits.

What to look for

Provide students with a small, poorly written function. Have them work in pairs to refactor it, then swap their refactored code with another pair. Each pair reviews the other's refactored code, answering: 'Did the refactoring improve readability? Did it introduce any new issues? Provide one specific suggestion for further improvement.'

• Apply
• Analyze
• Evaluate
• Create
• Relationship Skills
• Decision-Making
• Self-Management

Activity 03

• Think-Pair-Share
• 15 min · Pairs

Think-Pair-Share: Is This Refactoring Worth It?

Present a scenario where refactoring a module would take two days but the feature request is due in one day. Pairs argue for or against proceeding with refactoring. Share-out surfaces the real trade-offs between short-term velocity and long-term maintainability, which is a judgment engineers make constantly in industry.

Critique a given code snippet and propose refactoring strategies to improve its quality.

Facilitation Tip

During Think-Pair-Share: Is This Refactoring Worth It?, set a timer for each phase to keep discussions focused and equitable.

What to look for

Pose the question: 'Imagine you are a junior developer joining a project with significant technical debt. How would you advocate for the importance of refactoring to your team lead, and what initial steps would you propose to start improving code quality?'

• Understand
• Apply
• Analyze
• Self-Awareness
• Relationship Skills

Activity 04

• Jigsaw
• 35 min · Small Groups

Jigsaw: Refactoring Technique Cards

Assign each small group one refactoring technique, extract method, rename variable, replace magic number with constant, replace conditional with polymorphism. Groups study their technique, create a one-page visual explanation with a before/after example, then teach it to a mixed group. The class ends with a shared reference sheet.

Justify the importance of refactoring in the long-term maintainability of software.

Facilitation Tip

During Jigsaw: Refactoring Technique Cards, assign each group a technique to teach to the class to ensure accountability.

What to look for

Present students with a short code snippet containing 2-3 common code smells. Ask them to identify each smell by name and briefly explain why it is problematic. For example: 'Identify the code smell in lines 5-10 and explain why it needs refactoring.'

• Understand
• Analyze
• Evaluate
• Relationship Skills
• Self-Management

A few notes on teaching this unit

Teach refactoring by making technical debt tangible through concrete examples and structured practice. Avoid lectures on theory; instead, let students confront messy code directly and discover solutions collaboratively. Research shows that guided practice with immediate feedback helps students internalize refactoring as a habit, not an event.

Successful learning looks like students confidently identifying code smells, justifying refactoring choices with evidence, and applying techniques to improve code readability and maintainability. They should articulate why small, tested changes matter more than large rewrites.

---

Watch Out for These Misconceptions

• During Code Critique: Smell Identification Gallery Walk, watch for students who dismiss code smells as mere style preferences without considering their impact on future changes.

  Have students time themselves reading both the smelly and refactored versions of a code snippet during the gallery walk, then compare the results to show how smells slow development.

• During Pair Refactoring Lab: Before and After, watch for students who assume refactoring is only about making code shorter or faster.

  Ask them to add a new feature to their refactored code and observe how easily they can locate and modify the relevant logic compared to the original.

• During Think-Pair-Share: Is This Refactoring Worth It?, watch for students who believe refactoring should only happen when code is broken.

  Provide a scenario where code passes all tests but is difficult to extend, and have them role-play as a developer tasked with adding a feature to demonstrate the hidden costs.

---

Methods used in this brief

• Collaborative Problem-Solving
• Think-Pair-Share
• Jigsaw