Вынос условий в функции-предикаты: повышаем читаемость кода

Знаете это чувство? Вы открываете старый файл проекта, натыкаетесь на метод с названием processOrder(), а внутри него - три экрана if/else, вложенных друг в друга, как матрешка. Чтобы понять, почему заказ не проходит оплату, вам приходится держать в голове состояние пяти переменных и логику трех разных сервисов. Это больно. И чаще всего причина не в сложности бизнес-логики, а в том, что мы забыли про один простой прием: вынос условий в функции-предикаты.

Функция-предикат (или predicate function) - это небольшой кусок кода, который возвращает булево значение (true или false). Ее задача не делать работу, а отвечать на вопрос «Да или нет?». Когда мы заменяем громоздкие условия вызовами таких функций, код начинает дышать. Он становится похож на английский язык, а не на шифровку из математических знаков.

Почему длинные условия убивают ваш код

Представьте, что вы читаете книгу. Если каждая страница состоит из одного предложения длиной в абзац, вы быстро устанете. То же самое происходит с условиями. В программировании есть понятие когнитивной нагрузки. Чем больше логических операторов (&&, ||, !) и скобок в одной строке, тем сложнее мозгу разработчика распутать этот клубок.

Возьмем типичный пример проверки права пользователя на редактирование поста:

if (user.role === 'admin' || (user.id === post.authorId && post.status !== 'published') || user.isModerator) {
    editPost();
}

Чтобы понять эту строку, нужно прочитать ее дважды, а то и трижды. Где приоритет операторов? Что важнее: модераторство или авторство? А если завтра добавится новое правило для редакторов? Придется переписывать всю конструкцию, рискуя ошибиться со скобками. Такой код хрупкий. Его сложно тестировать изолированно, потому что условие «зашито» внутрь бизнес-процесса.

Анатомия идеального предиката

Не всякая функция, возвращающая boolean, является хорошим предикатом. Чтобы прием работал, нужно соблюдать несколько правил именования и структуры. Главное правило: имя функции должно описывать состояние или вопрос, а не действие.

Плохие имена:
checkUser() - Что именно проверяем?
validateData() - Слишком общо.
isTrue() - Бессмысленно.

Хорошие имена:
canEditPost()
hasExpiredSubscription()
isEligibleForDiscount()

Обратите внимание на префиксы: is, has, can, should. Они сразу сигнализируют коллеге по команде: «Эй, здесь ответ Да/Нет». Это создает семантическую связь между именем и поведением. Когда вы видите if (isEligibleForDiscount(cart)), вам не нужно заглядывать внутрь функции, чтобы понять смысл ветвления. Логика очевидна из названия.

Как внедрить предикаты в существующий код

Не нужно переписывать весь проект за один день. Начните с самого болезненного места. Найдите метод, где количество строк превышает 50, или там, где глубина вложенности if-ов больше двух уровней.

Шаги рефакторинга просты:

1. Изолируйте условие. Скопируйте сложное выражение из if в отдельную функцию.
2. Дайте ему говорящее имя. Подумайте, какой вопрос решает это условие.
3. Замените оригинал. Оставьте в основном методе только вызов новой функции.
4. Напишите тест. Убедитесь, что предикат работает корректно на граничных случаях.

Давайте разберем конкретный пример. Допустим, у нас есть система доставки еды. Нужно определить, можно ли оформить доставку бесплатно.

Было (плохо):

function calculateShipping(order, user, coupon) {
    // ... много кода ...
    if ((order.total > 1000 && user.tier !== 'basic') || 
        (coupon.code === 'FREE_DELIVERY' && !coupon.expired) ||
        (user.city === 'Moscow' && order.weight < 5)) {
        return 0;
    }
    // ... расчет стоимости ...
}

Стало (хорошо):

function isFreeDeliveryEligible(order, user, coupon) {
    return hasHighValueAndPremiumTier(order, user) ||
           hasValidFreeCoupon(coupon) ||
           isLightWeightInCapital(user, order);
}

function hasHighValueAndPremiumTier(order, user) {
    return order.total > 1000 && user.tier !== 'basic';
}

function hasValidFreeCoupon(coupon) {
    return coupon.code === 'FREE_DELIVERY' && !coupon.expired;
}

function isLightWeightInCapital(user, order) {
    return user.city === 'Moscow' && order.weight < 5;
}

Теперь основной метод calculateShipping выглядит так:

if (isFreeDeliveryEligible(order, user, coupon)) {
    return 0;
}

Разница колоссальная. Первая версия требовала анализа логики скидок и веса товаров одновременно. Вторая версия просто спрашивает систему: «Подходит ли этот заказ под бесплатную доставку?».

Когда предикаты становятся лишними

Любой инструмент можно использовать во вред. Не стоит создавать функцию-предикат для каждого тривиального сравнения. Если ваше условие выглядит как if (count > 0) или if (name === ''), выносить его в отдельную функцию isNotEmpty(count) - это оверинжиниринг. Вы создадите лишний слой абстракции, который придется читать, чтобы убедиться, что там нет скрытых ловушек.

Есть еще одна ловушка - «предикатная взрывуха». Это когда вы начинаете плодить сотни мелких функций, которые используются ровно один раз в одном месте. В таком случае код превращается в лабиринт прыжков по файлам. Правило большого пальца: если условие содержит более двух логических операторов или требует понимания домена (например, знаний о тарифных планах), выносите его в предикат. Если это простая проверка на null или пустоту - оставляйте инлайн.

Связь с SOLID и чистым кодом

Вынос условий в предикаты напрямую связан с принципом единственной ответственности (Single Responsibility Principle). Метод должен делать одну вещь. Функция processPayment() должна обрабатывать платеж. Она не должна заниматься проверкой валидности купона, анализом истории клиента и проверкой лимитов карты. Эти проверки - отдельные обязанности.

Когда вы выносите их в предикаты, вы фактически разделяете зоны ответственности. Бизнес-логика остается в сервисном слое, а правила валидации живут в своих маленьких функциях (или классах-валидаторах). Это делает систему модульной. Завтра менеджер попросит изменить правило для Москвы. Вы придете в функцию isLightWeightInCapital, измените вес с 5 кг на 3 кг, и все. Вам не нужно трогать сложный метод расчета доставки.

Практические советы для команды

• Группируйте предикаты. Если у вас их много, соберите их в отдельный модуль или класс OrderValidators. Так они будут под рукой.
• Документируйте граничные случаи. Внутри комментария к предикату напишите, почему выбрано такое правило. Например: «Вес до 5 кг актуален для курьеров на велосипедах, см. регламент от 2024 года».
• Избегайте побочных эффектов. Предикат должен быть чистой функцией. Он не должен менять состояние объекта, писать в базу данных или отправлять уведомления. Только чтение и возврат true/false.
• Используйте для фильтров коллекций. Предикаты идеально подходят для методов вроде filter() в JavaScript или Python. users.filter(isActive) читается гораздо лучше, чем users.filter(u => u.status === 1 && u.deletedAt === null).

Частые вопросы