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

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

Не для кого не секрет, что фронтэнд это одна из тех помоек, где если что-то работает, то лучше это не трогать, а если нет — переписать полностью.

Лучше один раз увидеть, чем сто раз услышать

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

Вводные

1. Карточка должна уметь занимать одно из трех положений. 1 — карточка инициализиролвана, 2 — пользователь потянул карточку вверх (раскрыл ее), 3 — пользователь смахнул карточку вниз, чтобы ее удалить.
   
   
   
2. Минимальный размер карточки — 50vh, максимальный — не ограничен (подразумевается возможность скрола в положении 2)

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

Например:



А схема действий на верхнем уровне выглядит примерно так, очень не замысловато:



Рассмотрим действие DragUp:



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

Сложность вызывает только классификация карточек по размерам. Мы должны классифицировать карточку как small чтобы предотвратить ее перетаскивание выше чем 50vh, карточка размера medium не должна подняться выше своей высоты (иначе она просто повиснет в «воздухе»), ну а карточка размера large не должна перетаскиваться выше, чем Y = 0 (верх экрана).

Хороший математик — ленивый математик. Классифицировать карточки по размерам и определять максимальную высоту перетаскивания — сложно, здесь стоит задуматься о том как представить эти карточки удобнее, не решать все в лоб (это как в математике, когда вы приводите все к общему знаменателю).

На данном этапе мы можем представить, что карточка отрисовывается в некоем виртульном вьюпорте, который способен премещаться вверх-вниз относительно реального вьюпорта, минимальная высота этого виртуального вьюпорта — 50vh, максимальная — 100vh.



Теперь общий параметр для карточек всех размеров в любых положениях (inited, opened) — это запас хода.

Схему обработки действия dragUp можно описать так:



Для действия dragDown все еще проще (можно, конечно, опять начать с кругов Эйлера, но все слишком очевидно) — единственное условие блокирующее dragDown — это то что карточка была проскролена, и будет выполнено действие scrollDown, а не dragDown.



А лидер в непритязательности к ограничивающим условиям — scroll. Единственное что следует учесть, что скрол становится возможен только в положении open, когда виртуальный и реальный вьюпорты полностью пересекаются. (и реализуем мы это условие через css, указав для положения open overflow-y)



И конечно же мы что-то «упустили» и это событие dragEnd, которое замыкает наше взаимодействие с карточками (а на самом деле с виртуальным вьюпортом) и на выходе определяет в каком положении мы должны оказаться.

Итог

По итогу первой части, где мы проводили инженерную подготовку, описывали ключевые параметры и схему действий мы плавно подошли к части 2, где с позиции разработчика будем это все реализовывать (такие вещи как действия dragUp, dragDown, определение запаса хода, описание конечных положений). В общем превращать схемы в код.