# Prefactoring: Clear the Way for Your New Feature

DevFeed: [Prefactoring: Clear the Way for Your New Feature](<https://devfeed.tech/articles/prefactoring-clear-the-way-for-your-new-feature-23872.md>)

Original publisher: [Read original article](<http://testing.googleblog.com/2026/07/prefactoring-clear-way-for-your-new.html>)

Author: Google Testing Bloggers (noreply@blogger.com)

Published: 2026-07-21T18:52:05Z

Content type: tutorial

Language: en

Sources: [Google Testing Blog](<https://devfeed.tech/sources/google-testing-blog.md>)

Topics: [Refactoring](<https://devfeed.tech/topics/refactoring.md>), [Code](<https://devfeed.tech/topics/code.md>)

Tags: [article](<https://devfeed.tech/tags/article.md>), [code](<https://devfeed.tech/tags/code.md>), [rahul-singal](<https://devfeed.tech/tags/rahul-singal.md>), [refactoring](<https://devfeed.tech/tags/refactoring.md>), [tott](<https://devfeed.tech/tags/tott.md>)

## AI overview

The article explains prefactoring, or preparatory refactoring: restructuring existing code before implementing a planned feature. It presents this as a way to make feature work fit the code naturally, speed up reviews, reduce bugs, and enable safer rollbacks.

## Source excerpt

This article was adapted from a Google Tech on the Toilet (TotT) episode. You can download a printer-friendly version of this TotT episode and post it in your office. By Rahul Singal "First make the change easy, then make the easy change." - paraphrased from Kent Beck You're working on a new feature, but the existing code wasn't written with future changes in mind. Trying to force the feature in directly gets complicated fast. One change leads to another, and before you know it you're already a few files deep fixing things you never planned to touch. Prefactoring (short for "preparatory refactoring") is the practice of reworking existing code to make it more suitable for an upcoming change before you actually implement the new functionality. Instead of cleaning up code as an afterthought or trying to force a new feature into an incompatible structure, you restructure the codebase first. Prefactoring helps you: Easily implement new features: Restructuring the codebase first ensures your new feature fits naturally into the code. Speed up reviews: It's easier to review the refactoring and the feature in separate changes. Avoid bugs: Isolating cleanups from functional logic can help prevent bugs. Roll back safely: If you need to roll back, it is much easier to revert small, focused changes. Here is a simplified example of a prefactoring change: Change 1 (Prefactoring) Extract display name helper to remove duplication. Change 2 (Feature) Add middle name support. + def get_display_name(user): + return f"{user.first_name} {user.last_name}" # Profile page - display_name = f"{user.first_name} {user.last_name}" + display_name = get_display_name(user) # Email template - greeting = f"Hi {user.first_name} {user.last_name}," + greeting = f"Hi {get_display_name(user)}," def get_display_name(user): - return f"{user.first_name} {user.last_name}" + return f"{user.first_name} {user.middle_name} {user.last_name}" You can prefactor a change that is already in review too! If your reviewe