Рефакторинг программного обеспечения: как переписывать код и не сойти с ума

Код гниёт. Это факт, с которым рано или поздно сталкивается каждый разработчик. Проект начинается с чистой архитектуры и понятной структурой, а через полгода ты уже боишься трогать класс UserManager, потому что непонятно, что отвалится. Рефакторинг программного обеспечения — это тот самый процесс, который возвращает коду живость. Но давайте честно: большинство команд делает это неправильно.

Что вообще такое рефакторинг и почему все делают вид, что понимают

Фаулер определил рефакторинг как изменение внутренней структуры кода без изменения его внешнего поведения. Звучит просто. На практике это значит: ты меняешь код, но все тесты продолжают проходить, а пользователи ничего не замечают.

Но тут нюанс. Многие путают рефакторинг с переписыванием. Рефакторинг — это мелкие, контролируемые изменения. Каждое из них тривиально. Переименовал переменную — закоммитил. Выделил метод — закоммитил. Переместил метод в другой класс — закоммитил. А переписывание — это когда ты создаёшь ветку rewrite-auth-module-v2, месяц там что-то делаешь, а потом вливаешь в мастер огромным коммитом "before/after". Это не рефакторинг. Это боль.

Правильный рефакторинг похож на замену фундамента у дома, где живут люди. Вы меняете одну балку за другой, не разрушая здание. Неправильный — как снос дома и строительство нового на том же месте.

Когда рефакторинг реально нужен

Есть очевидные сигналы. Code smells — они так называются не просто так. Запах кода чувствуешь интуитивно.

Длинные методы. Если метод не помещается на один экран — это проблема. Я видел методы на 500 строк. Там был и парсинг, и валидация, и запись в базу, и отправка email. Автор наверняка думал: "ну, это же один бизнес-процесс". Нет. Это пять разных ответственностей.

Дублирование. Скопипастили код в три места? Теперь нужно править баг в трёх местах. Забудете про одно — привет, regression.

Классы с кучей параметров. Конструктор с десятью аргументами — это крик о помощи. Скорее всего, класс делает слишком много.

# До: конструктор-монстр
class OrderProcessor:
    def __init__(self, db, logger, email_service, sms_service, 
                 payment_gateway, inventory, shipping, taxes,
                 discounts, notifications):
        # 10 параметров, и каждый что-то делает
        pass

# После: выделены контексты
class OrderProcessor:
    def __init__(self, payment: PaymentService, 
                 fulfillment: FulfillmentService,
                 notifications: NotificationService):
        self.payment = payment
        self.fulfillment = fulfillment
        self.notifications = notifications

Стрельба дробью — когда одинаковые изменения приходится вносить в множество классов. Отражает плохую декомпозицию.

Но самый надёжный индикатор — страх. Если перед изменением кода вы думаете "только бы ничего не сломать" — пора рефакторить. Код должен быть таким, чтобы изменения не пугали.

Методы рефакторинга: конкретные техники

Их десятки. Но по моему опыту, 80% времени вы используете штук пять.

Extract Method — самый частый. Выделяете кусок кода в отдельный метод с понятным названием.

# До: что происходит?
def process_order(order):
    # валидация
    if not order.items:
        raise ValueError("Empty order")
    if order.total < 0:
        raise ValueError("Negative total")
    # расчёт скидки
    discount = 0
    if order.customer.loyalty_level == "gold":
        discount = order.total * 0.1
    elif order.customer.loyalty_level == "silver":
        discount = order.total * 0.05
    # сохранение
    order.discount = discount
    order.status = "processed"
    db.save(order)
    return order

# После: каждый метод делает одно
def process_order(order):
    validate_order(order)
    order.discount = calculate_discount(order)
    order.status = "processed"
    db.save(order)
    return order

def validate_order(order):
    if not order.items:
        raise ValueError("Empty order")
    if order.total < 0:
        raise ValueError("Negative total")

def calculate_discount(order):
    rates = {"gold": 0.1, "silver": 0.05}
    return order.total * rates.get(order.customer.loyalty_level, 0)

Rename Variable/Method — звучит тривиально, но это полдела. Плохое название — это документация, которая врёт.

# До: что такое d? что такое temp?
def calc(d, t):
    temp = d * 0.15
    return temp + t

# После: названия говорят сами за себя
def calculate_total_with_tax(base_price, additional_fee):
    tax = base_price * TAX_RATE
    return base_price + tax + additional_fee

Replace Conditional with Polymorphism — когда у вас switch или куча if-else, выбирающих поведение.

# До: добавили новый тип — правим метод
def calculate_shipping(order):
    if order.type == "standard":
        return order.weight * 10
    elif order.type == "express":
        return order.weight * 25
    elif order.type == "overnight":
        return order.weight * 50 + 100

# После: новый тип — новый класс
class StandardShipping:
    def calculate(self, order):
        return order.weight * 10

class ExpressShipping:
    def calculate(self, order):
        return order.weight * 25

class OvernightShipping:
    def calculate(self, order):
        return order.weight * 50 + 100

# Использование
def calculate_shipping(order):
    return SHIPPING_STRATEGIES[order.type].calculate(order)

Extract Class — когда один класс растёт до 1000 строк. Обычно это означает смешение ответственностей.

Как не сломать всё при рефакторинге

Самое главное правило: тесты. Без тестов рефакторинг — это лотерея. Причём проигрышная.

Но тесты должны быть хорошими. Юнит-тесты на бизнес-логику, интеграционные на взаимодействие с базой и API. Если у вас 5% coverage — сначала пишите тесты, потом рефакторите.

Второе правило: маленькие шаги. Переименовали переменную — запустили тесты — закоммитили. Выделили метод — запустили тесты — закоммитили. Один коммит — одно изменение.

# Плохо: огромный коммит
git commit -m "Refactored auth module"

# Хорошо: атомарные коммиты  
git commit -m "Extract password validation into separate method"
git commit -m "Rename UserAuth to AuthenticationService"
git commit -m "Move session management to SessionService"

Третье: не смешивайте рефакторинг с изменением функциональности. Это соблазн. "Раз уж я тут правлю этот метод, добавлю фичу". Нет. Рефакторинг — только структурные изменения. Фича — отдельная задача. Иначе откатить что-то одно будет невозможно.

Четвёртое: code review. Да, на рефакторинг больно смотреть в ревью — много изменений, мало смысла в каждом отдельном файле. Но свежий глаз заметит, если вы случайно изменили поведение.

Кстати, для автоматизации рефакторинга программного обеспечения используют различные инструменты. IDE умеют переименовывать, извлекать методы, перемещать классы. IntelliJ, VS Code с плагинами — это база. Есть и специализированные инструменты для массовых изменений по кодовой базе. Но автоматика не заменит мозг. Она помогает с механикой, а архитектурные решения — за вами.

Code smells: самые частые проблемы в продакшене

За 10 лет я насмотрелся на разное. Вот топ проблем, которые встречаются постоянно.

God Object — один класс, который знает и делает всё. Типичный пример: Utils, Helper, Manager без конкретного назначения. К ним всё прилипает.

Feature Envy — метод одного класса постоянно обращается к данным другого. Скорее всего, метод находится не там.

# До: метод Report использует данные Order больше, чем самого Report
class Report:
    def generate_order_report(self, order):
        return f"Order #{order.id}: {order.items} items, ${order.total}"

# После: метод там, где данные
class Order:
    def generate_report(self):
        return f"Order #{self.id}: {self.items} items, ${self.total}"

Primitive Obsession — использование примитивов вместо выделенных типов. Телефон как строка, деньги как float, ID как int. Потом ловите баги с форматами и точностью.

# До: что можно передать вместо phone? любую строку
def send_sms(phone: str, message: str):
    pass

# После: тип гарантирует валидность
class PhoneNumber:
    def __init__(self, value: str):
        if not self._validate(value):
            raise ValueError(f"Invalid phone: {value}")
        self.value = value

def send_sms(phone: PhoneNumber, message: str):
    # Телефон уже валиден
    pass

Shotgun Surgery — одно изменение требует правок в десятке файлов. Обычно означает плохую модularity.

Практический пример: от.spaghetti к чистой архитектуре

Реальный кейс с одного проекта. Был класс PaymentHandler на 800 строк. Там было всё: валидация карты, вызов API платёжной системы, логирование, отправка чеков, обработка ошибок, retry-логика.

# Фрагмент "до" — типичный спагетти-код
class PaymentHandler:
    def process_payment(self, payment_data):
        # валидация карты
        if not payment_data.get('card_number'):
            self.logger.error("No card number")
            return {"status": "error", "message": "No card number"}
        if len(payment_data['card_number']) != 16:
            self.logger.error("Invalid card length")
            return {"status": "error", "message": "Invalid card"}
        
        # вызов API
        try:
            response = requests.post(
                self.api_url,
                json=payment_data,
                headers=self.headers
            )
        except requests.Timeout:
            self.logger.error("API timeout")
            self.send_alert("Payment API timeout")
            return {"status": "error", "message": "Timeout"}
        
        # и ещё 100 строк...

Рефакторинг занял неделю. Три дня на тесты, четыре — на изменения. Результат:

# После: каждый класс отвечает за своё
class PaymentProcessor:
    def __init__(self, validator: CardValidator, 
                 gateway: PaymentGateway,
                 receipt_service: ReceiptService):
        self.validator = validator
        self.gateway = gateway
        self.receipt_service = receipt_service
    
    def process(self, payment: Payment) -> PaymentResult:
        self.validator.validate(payment.card)
        result = self.gateway.charge(payment)
        if result.success:
            self.receipt_service.send(payment, result)
        return result

class CardValidator:
    def validate(self, card: Card) -> None:
        if not card.number:
            raise ValidationError("Card number required")
        if len(card.number) != 16:
            raise ValidationError("Invalid card number length")
        # Другие проверки...

class PaymentGateway:
    def charge(self, payment: Payment) -> PaymentResult:
        # Только взаимодействие с API
        pass

Теперь добавить новую платёжную систему — создать класс, реализующий интерфейс PaymentGateway. Изменить логику валидации — править один файл. Отправлять чеки через SMS вместо email — реализовать новый ReceiptService. Код стал гибким.

Рефакторинг — это не разовая акция, а постоянный процесс. У вас не будет времени "потихоньку переписать легаси". Выделите время в спринте, договаривайтесь с командой, делайте маленькими шагами.

Кстати, при рефакторинге легко пропустить ошибку в потоке изменений. Я пользуюсь Distiq — AI-бот анализирует каждый MR и подсвечивает потенциальные проблемы. Не catches всё подряд, но баги с логикой и неочевидные места находит. Экономит время на ревью и снижает вероятность того, что рефакторинг что-то сломает. Российский сервис, подключается к GitLab и GitHub за пару минут.