Программисты-новички мыслят скриптами: «сделай это, потом то, если получилось — делай третье». Это линейная логика функций, которая разваливается в ту же секунду, как только вы выходите за рамки учебной задачи. В реальном мире системы живут не инструкциями, а состояниями.
Инженерное мышление начинается там, где вы перестаете воспринимать код как список команд и начинаете видеть в нем сущности.
Сущность — это какой-то объект, который в каждый момент времени находится в конкретном «статусе». Возьмем обычную дверь с магнитным замком. Для джуна это функция
openDoor(). Для инженера это сущность со стейтом CLOSED. Когда мы прикладываем карту, происходит событие (Event). Если карта валидна, событие меняет состояние сущности на OPEN.🤔 Почему это критически важно? Потому что в сложной системе вам не нужно каждый раз проверять сотню условий и обкладываться костылями. Вы просто смотрите, в каком состоянии находится объект «здесь и сейчас». И в зависимости от этого разрешаете или запрещаете логику.
Фронтенд и кнопка-инвалид
Представьте, что у вас есть кнопка загрузки. Если вы мыслите инструкциями, вы напишете: «при клике отправь запрос». И поймаете один из классических багов, когда пользователь может нажать на кнопку 10 раз и отправит 10 запросов.
Инженер же, при клике, вешает на кнопку состояние
loading: true. Как только стейт изменился, кнопка сама становится disabled. Ей плевать, сколько раз пользователь по ней ударит — её текущее состояние диктует поведение. Событие «ответ от API» переключит стейт обратно в loading: false, и кнопка «оживет».Бэкэнд: Заказ не может телепортироваться
На бэкэнде логика состояний — это единственный способ не превратить код в непролазную лапшу из
if-else. Вместо бесконечных проверок «а что сейчас с заказом?», мы жестко описываем его жизненный цикл.Например:
1. Состояние:
NEW -> Событие: «Оплата прошла» -> Состояние: PAID.2. Состояние:
PAID -> Событие: «Передано курьеру» -> Состояние: DELIVERING.Вы физически не сможете перевести заказ в статус
DELIVERING, если он находится в статусе NEW. Система просто не пропустит такое событие для этого состояния. Вместо гигантских простыней проверок у вас есть четкий switch-case или набор изолированных классов, которые отвечают за конкретные переходы.Архитектурная чистота
Переключиться на стейт-ориентированное мышление больно, потому что запутанность кода на первый взгляд растет. Читать линейный скрипт проще, чем прыгать по состояниям. Но расширять такую систему — одно удовольствие. Если завтра бизнес придумает новый статус «Возвращено на склад», вы просто добавите один узел в стейт-машину и опишете один переход. Вам не придется перекапывать весь проект в поисках мест, где вы забыли поставить
if.💡 Кстати, профессиональные тестировщики часто рисуют «схемы состояний и переходов». Если вам повезло работать с таким, и у вас на руках есть такой документ, писать логику бэкэнда одно удовольствие. Вы просто переносите готовую карту в код.
Если что-то всё ещё звучит запутанно — пиши вопросы в комментах, я обязательно отвечу. А если всё разложилось по полочкам — ставь 🔥, так я пойму, что пост был полезен
10МДК