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.

• 12th Grade
• Computer Science
• 4 activities
• 15 min–50 min

Learning Objectives

1. Analyze a given code snippet for common code smells, such as duplication, long methods, or large classes.
2. Evaluate the impact of specific refactoring techniques on code readability and maintainability.
3. Propose and justify at least two refactoring strategies for a provided code example, explaining how they improve quality without altering functionality.
4. Compare the 'before' and 'after' versions of refactored code, articulating the specific design improvements made.

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.

Prepare & details

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.

Setup: Groups at tables with problem materials

Materials: Problem packet, Role cards (facilitator, recorder, timekeeper, reporter), Problem-solving protocol sheet, Solution evaluation rubric

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

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.

Prepare & details

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.

Setup: Groups at tables with problem materials

Materials: Problem packet, Role cards (facilitator, recorder, timekeeper, reporter), Problem-solving protocol sheet, Solution evaluation rubric

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

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.

Prepare & details

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.

Setup: Standard classroom seating; students turn to a neighbor

Materials: Discussion prompt (projected or printed), Optional: recording sheet for pairs

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

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.

Prepare & details

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.

Setup: Flexible seating for regrouping

Materials: Expert group reading packets, Note-taking template, Summary graphic organizer

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

Teaching This Topic

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.

What to Expect

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

Common Misconception

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.

What to Teach Instead

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.

Common Misconception

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

What to Teach Instead

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.

Common Misconception

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

What to Teach Instead

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.

Assessment Ideas

Quick Check

After Code Critique: Smell Identification Gallery Walk, 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.

Peer Assessment

During Pair Refactoring Lab: Before and After, have students swap their refactored code with another pair for review. Each pair answers: 'Did the refactoring improve readability? Did it introduce any new issues? Provide one specific suggestion for further improvement.'

Discussion Prompt

After Think-Pair-Share: Is This Refactoring Worth It?, 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?' Collect responses to assess their understanding of refactoring as a strategic practice.

Extensions & Scaffolding

• Challenge students who finish early to refactor a more complex piece of code, such as a class with multiple responsibilities or a function with nested conditionals.
• For students who struggle, provide a partially refactored version of the code with gaps they need to fill in, such as missing method extractions or renamed variables.
• Deeper exploration: Have students research and present on a specific code smell not covered in class, including its impact and refactoring techniques.

Key Vocabulary

Refactoring	The process of restructuring existing computer code without changing its external behavior. It aims to improve non-functional attributes of the software.
Code Smell	A surface indication in the code that usually corresponds to a deeper problem in the system. Examples include duplicated code or long methods.
Technical Debt	The implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer. Refactoring helps pay down this debt.
Extract Method	A refactoring technique where a fragment of code within a larger method is extracted into its own new method. This improves readability and reduces duplication.
Test Suite	A collection of test cases designed to be used to test a software program. A robust test suite acts as a safety net during refactoring, ensuring behavior remains unchanged.