Computer Science · Grade 11

Active learning ideas

Refactoring and Code Quality

Active learning works especially well for refactoring because students must see code smells firsthand and feel the impact of structural changes. Working with messy examples forces them to confront readability issues directly instead of just hearing about them. Students retain best when they practice fixes on real code, not abstract slides.

• Ontario Curriculum Expectations
• CS.HS.D.2
• CS.HS.P.5

• 30–45 min
• Pairs → Whole Class
• 4 activities

Activity 01

• Case Study Analysis
• 30 min · Pairs

Pair Refactor: Messy Method Challenge

Provide pairs with a long, duplicated function handling student grades. Partners identify issues like poor naming and redundancy, then refactor into smaller methods over 10 minutes. Pairs test outputs match originals and share one key change with the class.

Analyze the characteristics of 'bad code' and how refactoring addresses them.

Facilitation Tip

During Personal Project Polish, remind students to commit their original messy version before refactoring so they can compare changes later.

What to look for

Present students with a short code snippet exhibiting a common code smell (e.g., duplicated code). Ask them to identify the smell and write one sentence explaining why it is problematic. Collect responses to gauge understanding.

• Analyze
• Evaluate
• Create
• Decision-Making
• Self-Management

Activity 02

• Stations Rotation
• 45 min · Small Groups

Stations Rotation: Refactoring Types

Set up stations for extract method, rename variables, remove duplication, and simplify conditionals. Small groups spend 7 minutes per station refactoring code cards, recording before-and-after versions. Groups rotate and compare results in a final debrief.

Explain the importance of maintaining code quality in long-term software projects.

What to look for

Pose the question: 'Imagine you are joining a project with a large, existing codebase. What are the first three things you would look for to assess its quality and identify areas for refactoring?' Facilitate a class discussion on their responses.

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

Activity 03

• Case Study Analysis
• 35 min · Whole Class

Whole Class: Code Quality Debate

Display two code versions solving the same task. Class votes on quality, then discusses refactoring opportunities in real time. Students propose changes via shared editor, vote on best ones, and implement as a group.

Design a refactoring strategy for a given piece of inefficient or hard-to-read code.

What to look for

In pairs, students refactor a given piece of code. After refactoring, they swap their original and refactored versions. Each student writes two bullet points: one positive comment about their partner's refactored code and one suggestion for further improvement.

• Analyze
• Evaluate
• Create
• Decision-Making
• Self-Management

Activity 04

• Case Study Analysis
• 40 min · Individual

Individual: Personal Project Polish

Students select a prior unit's code project. They apply three refactoring techniques independently, document changes in a log, and self-assess using a quality rubric. Share one improvement in a quick gallery walk.

Analyze the characteristics of 'bad code' and how refactoring addresses them.

What to look for

Present students with a short code snippet exhibiting a common code smell (e.g., duplicated code). Ask them to identify the smell and write one sentence explaining why it is problematic. Collect responses to gauge understanding.

• Analyze
• Evaluate
• Create
• Decision-Making
• Self-Management

A few notes on teaching this unit

Start by showing students a poorly written method and having them articulate why it is hard to follow. Model the refactoring process step by step while narrating your decisions about names and structure. Emphasize that good code reads like clear instructions, not a puzzle. Avoid teaching refactoring as a set of rules to memorize; instead, connect each technique to concrete benefits like shorter debugging time or easier collaboration. Research shows students grasp concepts better when they see the immediate payoff of their work.

Students should demonstrate the ability to identify code smells, apply at least two refactoring techniques, and explain how their changes improve maintainability without altering behavior. They should also justify their choices during discussions and peer reviews. Evidence of learning appears in their refactored code and their ability to critique alternatives.

---

Watch Out for These Misconceptions

• During Pair Refactor, watch for students who assume refactoring changes program output. Redirect them to test outputs before and after changes to confirm behavior stays the same.

  During Pair Refactor, students will encounter code smells like duplicated logic or long methods. Redirect their attention to how clear variable names and modular functions make the code easier to follow without changing what it does.

• During Station Rotation, watch for students who believe adding more comments fixes messy code. Redirect them to examine how well-named variables and methods reduce the need for comments.

  During Code Quality Debate, students may claim that comments are always necessary. Redirect the discussion by having them compare heavily commented code with self-documenting code they refactored earlier.

• During Personal Project Polish, watch for students who see refactoring only as a bug-fixing tool. Redirect them to focus on structure improvements that prevent future bugs.

  During Personal Project Polish, students might treat refactoring as a last-minute fix. Redirect them to identify areas where small structural changes now will save time later in the project lifecycle.

---

Methods used in this brief

• Case Study Analysis
• Stations Rotation