Разработка логики приложения: от требований до чистого кода

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

Содержание

Материал разбит на смысловые блоки. Каждый отвечает на отдельный вопрос по теме.

•           Что такое логика приложения
•           Виды логики: бизнес-логика, логика представления и данных
•           Слои архитектуры приложения
•           Почему логику отделяют от интерфейса
•           Как проектировать логику: пошаговый подход
•           Сбор требований и сценариев
•           Описание правила и условий
•           Проектирование состояний
•           Управление состоянием приложения
•           Работа с данных: валидация и обработка
•           Обработка ошибок и крайних случаев
•           Популярные архитектурные подходы
•           Правила чистого кода
•           Тестирование логики приложения
•           Логика на клиенте и на сервере
•           Как описать логику в техническом задании
•           Рефакторинг запутанной логики
•           Инструменты и вспомогательные библиотеки
•           Частые ошибки при разработке логики

Дальше каждый пункт разобран подробно. Статья поможет собрать предсказуемое поведение продукта.

Что такое логика приложения

Логики в приложении отвечает на вопрос «что происходит». Интерфейс показывает кнопку, а логика решает, доступна ли она, что произойдёт после нажатия и какой результат увидит пользователя.

Пример из интернет-магазина. Кнопка «Оформить заказ» — это интерфейс. Проверка наличия товара, расчёт скидки, резервирование остатка и создание записи о заказе — логика.

Такие правила описывают ещё до написания кода. Они формулируются словами: если корзина пуста, оформление недоступно; если сумма выше порога, доставка бесплатная.

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

Виды логики: бизнес-логика, логика представления и данных

Разделение помогает понять, где какому коду место.

•           Бизнес-логика: правила предметной области. Как считается скидка, кто может отменить заказ, когда начисляются бонусы.
•           Логика представления: поведение интерфейса. Что показать при загрузке, какие поля скрыть, когда активировать кнопку.
•           Логика данных: получение и сохранение информации. Запросы к серверу, кеш, работа с локальным хранилищем.

Смешивать эти слои опасно. Если правило скидки живёт внутри экрана корзины, оно не сработает при оформлении через другие каналы: бота, сайт или админку.

Слои архитектуры приложения

Типовая архитектура делит код на уровни. Каждый уровень отвечает за свою зону и не лезет в чужую.

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

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

Почему логику отделяют от интерфейса

Причин несколько, и все они практические.

1.         Повторное использование: одни правила работают в мобильном клиенте, вебе и админке.
2.         Тестируемость: логику без интерфейса проверяют автотестами за секунды.
3.         Замена технологий: можно переписать экраны, сохранив ядро продукта.
4.         Параллельная работа: дизайнер и разработчик логики не блокируют друг друга.
5.         Понятность: правила собраны в одном месте, а не размазаны по обработчикам кнопок.

Обратите внимание: если бизнес-правило встречается в коде дважды, рано или поздно версии разойдутся. Правило должно существовать в единственном экземпляре.

Как проектировать логику: пошаговый подход

Проектирование идёт от смысла к коду. Порядок работы выглядит так.

Сбор требований и сценариев

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

Вопросы, которые задают на этом этапе:

1.         Кто выполняет действие и с какими правами.
2.         Какие условия должны выполниться до начала.
3.         Что происходит при успешном завершении.
4.         Какие есть альтернативные ветки.
5.         Что делать при ошибке или отказе.
6.         Какие данных изменяются в результате.

Описание правила и условий

Каждое бизнес-правило формулируют отдельно и просто. Хорошая формулировка проста и понятна человеку без технического образования.

Правила удобно записывать в виде условий: «если — то». Такой формат легко переносится в код и проверяется тестами.

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

Проектирование состояний

Любой процесс имеет набор состояний и переходов между ними. Заказ бывает новым, оплаченным, собранным, отправленным, завершённым или отменённым.

Полезно нарисовать схему переходов. Она просто показывает невозможные комбинации: например, отмену уже доставленного заказа.

Такой подход убирает целый класс багов. Вместо набора разрозненных флагов появляется одно понятное состояние.

Управление состоянием приложения

Состояние — это все данных, которые приложение помнит в момент работы: авторизован ли пользователя, что лежит в корзине, какой фильтр выбран.

Основные правила работы с состоянием:

•           Единый источник правды: одни и те же данных не дублируют в разных местах.
•           Явные переходы: состояние меняется через понятные действия, а не случайными присваиваниями.
•           Минимальный объём: хранят только то, что нельзя вычислить.
•           Разделение по областям: профиль, корзина и настройки живут отдельно.
•           Предсказуемость: одинаковые действия дают одинаковый результат.

Для сложных случаев используют конечные автоматы. Они описывают допустимые состояния и переходы, запрещая невозможные сочетания.

Работа с данных: валидация и обработка

Приложение не должно доверять входящим данным. Проверка обязательна на каждом уровне.

Валидацию делают дважды. На клиенте — чтобы быстро подсказать пользователю. На сервере — чтобы защитить систему, потому что клиент можно подделать.

Что проверяют чаще всего:

1.         Обязательность заполнения поля.
2.         Формат: почта, телефон, дата.
3.         Диапазон значений: количество, сумма, возраст.
4.         Уникальность: логин, номер документа.
5.         Права: может ли этот пользователя выполнить действие.

Бизнес-правила проверяют после формальной валидации. Сначала убеждаются, что данных корректны, затем — что операция допустима.

Обработка ошибок и крайних случаев

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

Крайние случаи, которые нужно предусмотреть:

•           пустой список и отсутствие результатов;
•           обрыв сети посередине операции;
•           повторное нажатие кнопки и дублирование запроса;
•           истёкший токен авторизации;
•           одновременное изменение одной записи двумя пользователями;
•           очень большие объёмы данных в списке.

Ошибки разделяют на две группы. Ожидаемые — недостаточно средств, товар закончился — показывают пользователю понятным текстом. Технические записывают в журнал и показывают обобщённое сообщение.

Важно! Повторяемые операции делают идемпотентными. Повторный запрос не должен создавать второй заказ или списывать деньги дважды.

Популярные архитектурные подходы

Готовые подходы экономят время: они уже решают типовые задачи разделения кода.

Выбирать подход стоит по размеру задачи. Для небольшого продукта строгая многослойность создаёт больше работы, чем пользы.

Правила чистого кода

Логику пишут так, чтобы её мог прочитать другой разработчик через год.

•           Понятные имена: функция называется по действию, переменная — по смыслу.
•           Одна функция — одна задача: если в описании появляется «и», стоит разделить.
•           Никаких магических чисел: значения выносят в именованные константы.
•           Ранний выход: проверки в начале функции вместо глубокой вложенности.
•           Минимум условий подряд: сложные ветвления заменяют таблицами правила или полиморфизмом.
•           Комментарии о причинах: объясняют «почему», а не «что делает строка».

Использовать общий стиль в команде важнее личных предпочтений. Другие правила оформления вторичны. Автоформатирование и линтер снимают споры и экономят время на ревью.

Тестирование логики приложения

Логика — самая тестируемая часть продукта. Она не зависит от интерфейса, поэтому проверяется просто и быстро.

Уровни проверок:

1.         Модульные тесты: отдельные функции и правила расчёта.
2.         Интеграционные: взаимодействие с базой и внешними сервисами.
3.         Сценарные: полный путь пользователя от начала до результата.

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

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

Логика на клиенте и на сервере

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

Клиентская часть отвечает за отзывчивость. Она проверяет формы, показывает подсказки, прячет недоступные кнопки. Всё это можно обойти, поэтому такие проверки нужны только для удобства.

Серверная часть отвечает за истину. Именно там пересчитывают суммы, проверяют права, списывают остатки и сохраняют результат. Другие клиенты — мобильное приложение, бот, интеграция — обращаются к тем же правилам.

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

Как описать логику в техническом задании

Разработка идёт быстрее, когда правила описаны заранее. Хорошее задание понятно и разработчику, и заказчику.

Что стоит включить в описание:

1.         Список ролей и их возможности в системе.
2.         Сценарии по шагам с успешным и альтернативными исходами.
3.         Формулировки правила в виде «если — то».
4.         Таблицу состояний и допустимых переходов.
5.         Список ограничений и настраиваемых значений.
6.         Реакцию на ошибки и крайние случаи.

Формулировки должны быть однозначными. Фраза «скидка для постоянных клиентов» допускает разные трактовки, а «скидка 10% при пятом заказе за 90 дней» — нет.

С помощью таблиц описывать правила проще всего. Строки — условия, столбцы — результат. Такой формат не оставляет возможности для двойного толкования.

Обратите внимание: значения вроде процентов и сроков стоит помечать как настраиваемые. Иначе каждое изменение потребует нового релиза.

Рефакторинг запутанной логики

Со временем код обрастает исключениями. Разобраться в нём становится сложно даже автору.

Признаки того, что пора наводить порядок:

•           одна функция занимает несколько экранов;
•           условия вложены на четыре уровня и глубже;
•           одно правило встречается в разных файлах;
•           правку невозможно внести без страха что-то сломать;
•           новые сотрудники неделями разбираются в поведении продукта.

Порядок наводят постепенно, а не переписыванием всего сразу. Сначала логику покрывают тестами — они фиксируют текущее поведение. Затем правила по одному выносят в отдельный слой и проверяют, что тесты по-прежнему проходят.

Такой подход даёт возможность улучшать код без остановки разработки. С помощью тестов видно, что поведение не изменилось, а команда продолжает выпускать новые функции.

Инструменты и вспомогательные библиотеки

Набор инструментов зависит от языка и платформы, но категории общие.

•           Библиотеки состояния: предсказуемое хранение и обновление данных.
•           Валидаторы схем: описание правила проверки в одном месте.
•           Тестовые фреймворки: запуск проверок и отчёты о покрытии.
•           Линтеры и форматтеры: единый стиль и раннее выявление проблем.
•           Логирование и мониторинг: видимость того, как логика ведёт себя в бою.
•           Диаграммы и схемы: визуальное описание состояний и процессов.

Как оценить сроки разработки логики

Оценка логики сложнее оценки интерфейса. Экран видно на макете, а количество правила и крайних случаев — нет.

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

Запас закладывают обязательно. Обычно берут 20–30 процентов сверху: часть крайних случаев обнаруживается уже в процессе.

С помощью описанных заранее сценариев оценка получается точнее. Когда правила сформулированы, разработчик считает работу, а не гадает о ней.

Частые ошибки при разработке логики

Типичные проблемы повторяются в большинстве проектов.

1.         Бизнес-правила внутри обработчиков кнопок.
2.         Дублирование одного правила в нескольких местах.
3.         Проверка данных только на клиенте.
4.         Набор булевых флагов вместо явного состояния.
5.         Функции на сотни строк с глубокой вложенностью.
6.         Молчаливое проглатывание ошибок без записи в журнал.
7.         Значения бизнес-правил, зашитые прямо в код.
8.         Отсутствие тестов на денежные и правовые операции.

Проверка простая. Попробуйте описать правило словами и найти его в коде. Если оно встречается в трёх местах или не находится вовсе, структуру стоит пересобрать.

Хорошая логика приложения предсказуема и описана словами до написания кода. Разделяйте слои, храните каждое правило в одном месте и проверяйте тестами то, что дороже всего сломать.