sammutcode.com

Функции и параметры: как разбивать код на части

June 21, 2026 · Основы программирования

Помню свой первый коммерческий проект: скрипт на Python, который парсил данные, обрабатывал и выводил отчёт. Всё это уместилось в одной функции main() строк на 300. Работало. Но когда через месяц потребовалось добавить новый источник данных, я потратил три дня, распутывая логику и ловя регрессии. Тогда я осознал: код должен быть разбит на функции не ради красоты, а ради выживания проекта. В этом материале я поделюсь правилами и приёмами, которые помогают мне и моей команде писать поддерживаемый код. Разберём, что такое функция, как выбирать параметры, когда выносить блок в отдельную функцию и какие ошибки чаще всего встречаются у начинающих.

Зачем вообще нужны функции

Функция — это именованный блок кода, который выполняет одну конкретную задачу. Вместо того чтобы писать один и тот же набор операций каждый раз, вы описываете их один раз и затем вызываете по имени. Это база, но за ней стоит больше, чем просто принцип DRY (Don’t Repeat Yourself).

Пример без функции:

# Расчёт стоимости с налогом для разных товаров
price1 = 100
tax = 0.2
total1 = price1 + price1 * tax
print(f"Цена с налогом: {total1}")

price2 = 200
total2 = price2 + price2 * tax
print(f"Цена с налогом: {total2}")

То же самое с функцией:

def calculate_total(price, tax_rate=0.2):
    return price + price * tax_rate

print(f"Цена с налогом: {calculate_total(100)}")
print(f"Цена с налогом: {calculate_total(200)}")

Почему это важно

  • Меньше дублирования кода. Если нужно изменить логику расчёта налога, вы правите в одном месте, а не ищете все копипасты по проекту. В одном проекте мы вынесли валидацию email в отдельную функцию, и когда потребовалось добавить проверку на корпоративные домены, изменение затронуло только одну строчку, а не десятки мест.
  • Читаемость. Название функции сразу говорит, что она делает, и вам не нужно вчитываться в детали реализации. Хорошо названная функция работает как оглавление: вы видите общую картину, не проваливаясь в детали.
  • Тестируемость. Можно написать юнит-тест на функцию изолированно, не поднимая всю систему. Это особенно важно, когда логика начинает обрастать условиями.
  • Повторное использование. Одну функцию можно вызывать в разных частях программы, экономя время и снижая риск ошибок при копировании.

Как правильно называть функции

Имя функции — это её документация. Если имя понятное, комментарии часто не нужны. Я всегда говорю джуниорам: представьте, что имя функции будет читать другой разработчик, который видит ваш код впервые. Он должен сразу понять, что функция делает, не заглядывая в реализацию.

Хорошие имена:

  • calculate_total_price
  • validate_email
  • load_user_data
  • send_notification

Плохие имена:

  • func1
  • do_stuff
  • process_data (слишком абстрактно)

Правило: имя должно отвечать на вопрос «что делает?»

Если вы не можете сформулировать, что делает функция, значит, она делает слишком много или неясно. В этом случае нужно разбить её на части. Однажды на код-ревью я увидел функцию process(). Она принимала строку, и внутри в зависимости от флага то парсила JSON, то отправляла email, то логировала. Пришлось разбить на три отдельные функции с понятными именами: parse_json_payload, send_notification_email и log_event. После этого код стал не только понятнее, но и тестироваться каждая часть отдельно.

Параметры функции: что это и зачем

Параметры — это входные данные, которые функция получает при вызове. Они позволяют одной функции работать с разными значениями, делая её универсальной. Но выбор параметров — это проектирование интерфейса функции, и от него зависит, насколько удобно будет ей пользоваться.

Пример:

def greet(name):
    print(f"Привет, {name}!")

greet("Анна")
greet("Иван")

Здесь name — параметр. При вызове функции вы передаёте аргументы ("Анна", "Иван").

Параметры vs аргументы

  • Параметр — переменная в определении функции.
  • Аргумент — значение, которое вы передаёте при вызове.

Это различие важно при обсуждении сигнатур функций и отладке. Когда вы видите ошибку «missing argument», вы понимаете, что забыли передать значение. Я часто прошу джуниоров явно проговаривать: «функция принимает параметр user_id, а мы передаём аргумент 42» — это помогает избежать путаницы в обсуждениях.

Как выбирать параметры: практические правила

Выбор параметров — это не просто «что удобно», а дизайн интерфейса функции. От этого зависит, насколько удобно будет пользоваться функцией. Я часто вижу функции, которые принимают множество флагов и позиционных аргументов, и понять, что передавать, можно только заглянув в исходники. Вот несколько правил, которые я использую в своей практике.

1. Делайте параметры конкретными

Плохо:

def process_data(data, flag1, flag2):
    if flag1:
        # что-то делаем
    if flag2:
        # что-то другое

Лучше:

def process_data(data, sort=False, filter_inactive=False):
    if sort:
        # сортируем
    if filter_inactive:
        # фильтруем

Именованные параметры делают вызов самодокументируемым. В Python можно использовать keyword arguments при вызове, чтобы явно указать, что за что отвечает: process_data(data, sort=True, filter_inactive=False). В других языках — передавать объект с полями. Это спасает, когда через полгода возвращаешься к своему же коду и не помнишь, что означал второй True.

2. Не передавайте «всё подряд»

Если функция принимает 8 параметров, это сигнал, что она делает слишком много. Вместо этого можно вынести часть логики в отдельные функции или объединить связанные параметры в структуру (например, словарь или класс).

Пример:

def create_user(name, email, age, address, phone, is_active, role, department):
    # создание пользователя

Лучше:

class UserData:
    def __init__(self, name, email, age, address, phone, is_active, role, department):
        self.name = name
        self.email = email
        # ...

def create_user(user_data: UserData):
    # создание пользователя

или

def create_user(name, email, **kwargs):
    # kwargs содержит остальные параметры

Я обычно ввожу правило: если параметров больше трёх, стоит задуматься. В одном проекте мы создали дата-классы для конфигураций, и количество ошибок при вызове функций резко сократилось. Разработчики перестали путать порядок аргументов, а добавление нового поля не требовало менять сигнатуры десятков функций.

Когда выносить код в отдельную функцию

Не каждое дублирование требует выноса в функцию, но есть чёткие сигналы, что пора это сделать. Я смотрю на код и задаю себе несколько вопросов, которые помогают принять решение.

1. Повторяющийся код

Если вы копируете один и тот же блок кода больше одного раза — это повод вынести его в функцию. Даже две одинаковые строки могут быть кандидатом, если они несут смысловую нагрузку. В одном проекте мы обнаружили, что логика форматирования даты дублировалась в 15 местах; после выноса в функцию format_timestamp мы не только сократили код, но и исправили баг с часовыми поясами в одном месте, вместо того чтобы править 15 копий.

2. Сложная логика в одном блоке

Если внутри функции появляется вложенность условий, циклов и других операций, разбейте её на подфункции. Это улучшает читаемость и позволяет тестировать части по отдельности.

Пример:

def process_order(order):
    if order.status == "new":
        # проверка наличия
        for item in order.items:
            if item.stock < item.quantity:
                raise Exception("Нет в наличии")
        # расчёт скидки
        if order.customer.is_vip:
            order.discount = 0.1
        # ... ещё 20 строк

Лучше:

def check_stock(order):
    for item in order.items:
        if item.stock < item.quantity:
            raise Exception("Нет в наличии")

def apply_discount(order):
    if order.customer.is_vip:
        order.discount = 0.1

def process_order(order):
    if order.status == "new":
        check_stock(order)
        apply_discount(order)
        # ...

Когда я вижу функцию с тремя уровнями вложенных if, я прошу автора подумать, можно ли выделить логические шаги. Обычно это возможно, и код становится не только чище, но и безопаснее: изменения в одном шаге не затрагивают другие.

3. Непонятное назначение блока кода

Если вы не можете описать блок кода в одном предложении, значит, он делает слишком много. Разбейте его на части. Это правило я использую сам: если не могу дать короткое имя блоку, значит, он требует декомпозиции. Например, блок из 15 строк, который и валидирует, и форматирует, и сохраняет — явный кандидат на разделение.

Возвращаемые значения и чистые функции

Функция может возвращать результат с помощью return. Это позволяет использовать её в выражениях и строить цепочки преобразований. Но важно понимать разницу между чистыми и нечистыми функциями — это влияет на тестируемость и предсказуемость кода.

Пример:

def add(a, b):
    return a + b

result = add(2, 3)  # result = 5

Чистые функции

Чистая функция — это функция, которая:

  • всегда возвращает одинаковый результат при одинаковых входных данных;
  • не изменяет внешние переменные и не зависит от них (нет побочных эффектов).

Пример чистой функции:

def multiply(a, b):
    return a * b

Пример нечистой функции:

total = 0

def add_to_total(value):
    global total
    total += value
    return total

Чистые функции проще тестировать и отлаживать, потому что их поведение предсказуемо. В функциональном программировании это основа. Я стараюсь писать чистые функции везде, где это возможно, а побочные эффекты (ввод-вывод, изменение состояния) выносить в отдельные обёртки. Это сильно упрощает юнит-тестирование: не нужно мокать базы данных или файловую систему. Например, функцию, которая считает скидку, можно протестировать, просто передав разные входные данные, не поднимая весь контекст заказа.

Практический пример: разбиение кода на функции

Давайте разберём реальный сценарий: у вас есть список пользователей, и нужно загрузить данные, проверить email, отфильтровать активных и посчитать количество. Типичный код новичка — всё в одной простыне. Я покажу, как это выглядит до и после рефакторинга, и объясню, какие преимущества это даёт.

Без функций:

users = [
    {"name": "Анна", "email": "[email protected]", "active": True},
    {"name": "Иван", "email": "ivan@", "active": True},
    {"name": "Петр", "email": "[email protected]", "active": False},
]

active_count = 0
for user in users:
    if user["active"]:
        if "@" in user["email"] and "." in user["email"]:
            active_count += 1

print(f"Активных пользователей с валидным email: {active_count}")

С функциями:

def is_valid_email(email):
    return "@" in email and "." in email

def is_active(user):
    return user.get("active", False)

def count_active_with_valid_email(users):
    count = 0
    for user in users:
        if is_active(user) and is_valid_email(user.get("email", "")):
            count += 1
    return count

users = [
    {"name": "Анна", "email": "[email protected]", "active": True},
    {"name": "Иван", "email": "ivan@", "active": True},
    {"name": "Петр", "email": "[email protected]", "active": False},
]

print(f"Активных пользователей с валидным email: {count_active_with_valid_email(users)}")

После такого рефакторинга код становится не только чище, но и гибче. Если завтра потребуется добавить проверку на домен email, вы измените только функцию is_valid_email, не трогая остальную логику. А если нужно будет загружать данные из API вместо статического списка — замените источник данных, не меняя бизнес-логику. Каждая функция тестируется отдельно, и вы можете быть уверены, что изменения не сломают другие части. В реальном проекте такой подход сэкономил нам часы отладки, когда внезапно поменялись требования к валидации.

Типичные ошибки новичков

На ревью кода я часто вижу одни и те же паттерны, которые мешают поддерживать код. Вот основные из них и способы их избежать.

1. Функции, которые делают слишком много

Функция должна решать одну задачу. Если в описании появляется «и ещё…», пора разбивать. Пример: функция process_user, которая и валидирует, и сохраняет в базу, и отправляет письмо. Разделите на validate_user, save_user, send_welcome_email. Это не только улучшит читаемость, но и позволит переиспользовать каждую часть независимо.

2. Слишком много параметров

Более 3–4 параметров — это уже сигнал. Используйте структуры данных или объекты. Я часто вижу функции с 7-8 параметрами, где половина — необязательные флаги. Это усложняет понимание и вызов. Вместо этого создайте класс конфигурации или используйте словарь с осмысленными ключами.

3. Непонятные имена

func1, process, helper — такие имена ничего не говорят о назначении функции. Даже если функция вспомогательная, дайте ей осмысленное имя, например format_timestamp. Хорошее имя экономит время при чтении кода и уменьшает потребность в комментариях.

4. Отсутствие документации

Даже если код простой, добавьте короткий комментарий или docstring. Это особенно важно для публичных API функций. Я прошу команду писать хотя бы одну строку о том, что функция принимает и возвращает. Например:

def is_valid_email(email: str) -> bool:
    """Проверяет, что email содержит '@' и '.'."""
    return "@" in email and "." in email

Такая документация помогает и при автодополнении в IDE, и при генерации документации.

Практический чек-лист: как разбивать код на функции

Перед тем как писать код, я задаю себе несколько вопросов. Этот чек-лист помогает мне и моей команде не создавать монолиты и сразу проектировать код правильно.

  • Что делает этот блок кода? Если ответ не в одном предложении — разбейте.
  • Повторяется ли этот код? Если да — вынесите в функцию.
  • Можно ли назвать этот блок понятным именем? Если нет — переработайте.
  • Сколько параметров у функции? Если больше 4 — подумайте о структуре данных.
  • Можно ли протестировать эту функцию отдельно? Если нет — упростите.

Если на все вопросы ответили «да» — функция спроектирована хорошо. Я часто вешаю этот список на стену в опенспейсе, чтобы джуниоры могли сверяться с ним во время код-ревью.

FAQ: частые вопросы о функциях и параметрах

1. Сколько строк должна быть у функции?
Нет жёсткого правила, но я обычно держу функции в пределах 5–20 строк. Если функция больше — это повод задуматься о декомпозиции. Однако не стоит дробить искусственно: если функция делает одну простую операцию, но требует 30 строк из-за обработки ошибок, это нормально. Главное — читаемость. Когда функция перестаёт помещаться на одном экране, я начинаю искать логические части для выделения.

2. Когда использовать классы вместо функций?
Классы нужны, когда у вас есть состояние и поведение, связанные с этим состоянием. Например, пользователь с именем, email и методами для изменения данных. Если же вам нужно просто преобразовать данные, функции достаточно. В Python часто можно начать с функций, а когда появляется потребность хранить состояние — обернуть их в класс.

3. Можно ли использовать глобальные переменные внутри функций?
Можно, но лучше избегать. Глобальные переменные усложняют тестирование и отладку, создают неявные зависимости. Я всегда рекомендую передавать всё необходимое через параметры. Это делает функцию более предсказуемой и независимой от контекста выполнения.

4. Что делать, если функция возвращает несколько значений?
В Python можно вернуть кортеж: return name, age. В других языках — использовать объекты или структуры данных. Но если значений больше трёх, возможно, стоит создать класс или именованный кортеж для ясности. Например, return UserInfo(name, email, age) вместо простого кортежа — так сразу понятно, что есть что.

Заключение: как применять это на практике

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

Если вы узнали что-то новое, попробуйте применить это в своём текущем проекте. Найдите функцию, которая делает слишком много, и разбейте её. Результат вас удивит. А если хотите помочь коллегам — поделитесь этой статьёй.