Computer Science · 11th Grade

Active learning ideas

Refactoring and Code Quality

Students learn refactoring best when they see messy code firsthand and discuss how to improve it. Active learning lets them analyze real examples, practice incremental changes, and recognize why clean code matters for maintenance and teamwork. This hands-on approach builds both technical skills and professional judgment.

• Common Core State Standards
• CSTA: 3B-AP-16

• 20–35 min
• Pairs → Whole Class
• 4 activities

Activity 01

• Gallery Walk
• 30 min · Small Groups

Gallery Walk: Code Smell Identification

Post five code samples around the room, each demonstrating a different code smell (long method, duplicate code, magic numbers, deeply nested logic, poor naming). Student groups rotate and annotate each sample with the smell they identify and a suggested fix. Debrief as a class to build a shared catalog of smells.

Explain the purpose and benefits of code refactoring.

Facilitation Tip

During the Gallery Walk, circulate with a checklist of common smells so students practice looking for concrete patterns, not just general opinions.

What to look for

Present students with a short code snippet containing 2-3 common code smells (e.g., a long method, duplicated code). Ask them to identify the smells and write one sentence explaining why each is a problem.

• Understand
• Apply
• Analyze
• Create
• Relationship Skills
• Social Awareness

Activity 02

• Peer Teaching
• 35 min · Pairs

Pair Programming: Live Refactor

Partners take turns being the 'driver' and 'navigator' while refactoring a provided messy function. The navigator identifies smells and suggests changes; the driver implements them. After 10 minutes they swap roles. Both write a brief reflection on what changed and why it's better.

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

Facilitation Tip

For the Pair Programming Live Refactor, set a strict 5-minute timer for each tiny change to reinforce incremental progress and small tests.

What to look for

Students exchange small, refactored code examples. For each example, they answer: 'Did the refactoring improve readability? Provide one specific example.' and 'Is the external behavior likely unchanged? Why or why not?'

• Understand
• Apply
• Analyze
• Create
• Self-Management
• Relationship Skills

Activity 03

• Peer Teaching
• 25 min · Individual

Before/After Code Review

Show students a before-and-after refactoring pair and ask them to write three specific observations about what improved. Then have them apply the same thinking to their own code from a previous project. Volunteers share one refactoring they made and explain the reasoning.

Justify refactoring decisions based on principles of code readability and maintainability.

Facilitation Tip

In the Before/After Code Review, require students to write a one-sentence summary of what changed and why, to focus their observations on impact rather than just surface edits.

What to look for

Pose the question: 'Imagine you have a deadline approaching and discover a significant code smell. What factors would you consider when deciding whether to refactor now or defer the work, and what are the potential consequences of each choice?'

• Understand
• Apply
• Analyze
• Create
• Self-Management
• Relationship Skills

Activity 04

• Peer Teaching
• 20 min · Whole Class

Refactoring Debate: Is It Worth It?

Present a scenario: a working but messy 200-line function that needs a small feature added. Half the class argues for adding the feature directly; the other half argues for refactoring first. Groups build their case, present it, and the class votes. Discuss how context (deadline, team size, codebase age) affects the right answer.

Explain the purpose and benefits of code refactoring.

Facilitation Tip

In the Refactoring Debate, assign roles in advance so students prepare arguments for or against refactoring under time pressure.

What to look for

Present students with a short code snippet containing 2-3 common code smells (e.g., a long method, duplicated code). Ask them to identify the smells and write one sentence explaining why each is a problem.

• Understand
• Apply
• Analyze
• Create
• Self-Management
• Relationship Skills

A few notes on teaching this unit

Teach refactoring as a daily habit, not a one-time project. Use real student code or anonymized classroom examples to keep discussions relevant and authentic. Emphasize that refactoring is about reducing future costs, not fixing present bugs. Model curiosity: ask students to explain what they see and why it matters, then guide them toward cleaner solutions through targeted prompts rather than direct fixes.

By the end of these activities, students should confidently identify code smells, apply small refactoring steps, and explain how improved code structure benefits future work. They should also weigh trade-offs between refactoring and immediate delivery, showing informed decision-making.

---

Watch Out for These Misconceptions

• During the Gallery Walk: Code Smell Identification, students may claim refactoring means rewriting everything.

  Use the Gallery Walk’s examples to point out that each smell has a small, focused fix—like renaming a variable or extracting a method—so students see refactoring as a series of targeted improvements rather than a complete rewrite.

• During the Pair Programming: Live Refactor, students may skip tests and change behavior while refactoring.

  Require pairs to write and run a quick test after every small change, using the activity’s shared testing environment to confirm behavior stays the same before moving on.

• During the Refactoring Debate: Is It Worth It?, students may argue that if code works, refactoring is unnecessary.

  Use the debate’s discussion prompts to have students calculate the cost of future bugs or onboarding time caused by unreadable code, tying refactoring directly to maintainability and team efficiency.

---

Methods used in this brief

• Gallery Walk
• Peer Teaching