Computer Science · 11th Grade · Object-Oriented Programming · Weeks 19-27

Refactoring and Code Quality

Improving the internal structure of existing code without changing its external behavior.

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

About This Topic

Refactoring is the process of improving the internal structure of existing code without changing what it does. Students often think of coding as write-once work, but professional developers spend a significant portion of their time improving code they or others already wrote. CSTA standard 3B-AP-16 specifically asks students to evaluate and refine computational artifacts, making refactoring a core 11th-grade competency.

A central concept in refactoring is the 'code smell', a term coined by Martin Fowler to describe symptoms in code that suggest structural problems. Long methods, duplicate code, deeply nested conditionals, and poorly named variables are all code smells. Learning to recognize them gives students a vocabulary for discussing code quality that goes beyond 'it works' or 'it doesn't work.'

Active learning is valuable here because code quality involves judgment that improves through practice and feedback. Students need to read real (and often imperfect) code, argue about what to improve, and see how refactored versions compare. Peer review activities and live refactoring sessions are more effective than lecture-based instruction for building this skill.

Key Questions

1. Explain the purpose and benefits of code refactoring.
2. Analyze common 'code smells' that indicate a need for refactoring.
3. Justify refactoring decisions based on principles of code readability and maintainability.

Learning Objectives

• Analyze common code smells in a given code snippet and identify specific areas needing refactoring.
• Evaluate the impact of refactoring on code readability and maintainability using qualitative and quantitative metrics.
• Justify proposed refactoring strategies by referencing established software design principles.
• Compare the 'before' and 'after' versions of refactored code to demonstrate improved structure without altered functionality.
• Create a refactored version of a small program that addresses identified code smells.

Before You Start

Basic Object-Oriented Programming Concepts

Why: Students need to understand classes, objects, methods, and properties to effectively refactor object-oriented code.

Control Flow Statements

Why: Understanding loops, conditionals, and sequential execution is fundamental to analyzing and modifying code structure.

Functions and Methods

Why: Students must be able to identify and work with reusable blocks of code to understand concepts like 'long methods' or extracting methods.

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 source code that usually corresponds to a deeper problem in the system. Examples include long methods or duplicate code.
Maintainability	The ease with which software can be understood, modified, and tested. Refactoring aims to increase maintainability.
Readability	The ease with which human readers can comprehend the purpose, control flow, and operation of source code. Refactoring often improves readability.
Technical Debt	The implied cost of rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer. Refactoring helps pay down technical debt.

Watch Out for These Misconceptions

Common Misconception

Refactoring means rewriting code from scratch.

What to Teach Instead

Refactoring is specifically about making small, incremental improvements to existing code while keeping its behavior unchanged. Rewriting from scratch is a different, and often riskier, strategy. Professional refactoring typically happens in small steps, with tests verifying that behavior hasn't changed after each step.

Common Misconception

If the code works, there's no reason to refactor it.

What to Teach Instead

Working code can still be costly to maintain, extend, or debug. Code that works but is hard to understand creates problems when requirements change or when someone else needs to modify it. The goal of refactoring is to reduce the future cost of the codebase, not to fix current bugs.

Common Misconception

Refactoring should be done all at once as a separate project phase.

What to Teach Instead

Effective refactoring is continuous and incremental, a small improvement made whenever you touch code. The 'boy scout rule' says leave the code a little cleaner than you found it. Saving refactoring for a dedicated phase usually means it never happens, or happens too late when the codebase is already deeply entangled.

Active Learning Ideas

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.

30 min·Small Groups

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.

35 min·Pairs

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.

25 min·Individual

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.

20 min·Whole Class

Real-World Connections

• Software engineers at Google use refactoring daily to improve the performance and stability of complex systems like the search engine or Android operating system. This ensures billions of users have a reliable experience.
• Game developers at Blizzard Entertainment constantly refactor code for titles like World of Warcraft. This allows them to add new features, fix bugs, and optimize performance for millions of players without breaking existing gameplay mechanics.
• Financial technology companies, such as Stripe, rely on clean, maintainable code for their payment processing platforms. Refactoring helps ensure security, reduce errors, and allows for rapid updates to comply with evolving regulations.

Assessment Ideas

Quick Check

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.

Peer Assessment

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?'

Discussion Prompt

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?'

Frequently Asked Questions

What is refactoring in software development?

Refactoring means restructuring existing code to improve its clarity, organization, or efficiency without changing what the code actually does. It's not bug fixing and it's not adding features, it's purely improving the internal design. Common examples include renaming variables to be more descriptive, extracting repeated code into a function, or breaking a long method into smaller, focused ones.

What are code smells and why do they matter?

Code smells are patterns in code that suggest the structure could be improved, even if the code currently works. Examples include duplicate code (the same logic repeated in multiple places), long methods (a function doing too many things), and magic numbers (unexplained numeric constants). Smells don't guarantee a problem, but they're useful signals that the code might be harder to maintain or extend than necessary.

How can active learning approaches improve students' refactoring skills?

Refactoring requires aesthetic judgment, recognizing what 'better' means in context, which develops through practice and discussion, not memorization. Activities like code reviews, pair refactoring sessions, and before/after comparisons give students repeated exposure to the decisions developers actually make. Discussing disagreements ('should this be two functions or one?') builds the reasoning that makes good refactoring intuitive.

How do tests relate to refactoring?

Tests are what make refactoring safe. If you have a test suite that verifies the code's current behavior, you can refactor with confidence, run the tests after each change and any behavior change shows up immediately. Without tests, refactoring is risky because you can't easily verify that your structural improvements didn't accidentally break something. This is why 'refactoring' is typically paired with 'test-driven development' in professional practice.