Что скрывают комментарии в тестах

Работая с автотестами на разных проектах, я часто сталкивалась с тем, что к коду тестов люди относятся не так, как к продуктовому. Причем это касается и разработчиков, и тестировщиков, и менеджеров. Коду тестов прощаются грехи, недопустимые в продуктовом коде. Хорошо это или плохо? Зависит от ситуации. В этой статье – сборник больных антипаттернов из моего опыта.

👉 @seniorFront

shop loader

Это SVG картинка, анимированная библиотекой TweenMax.

👉 @seniorFront

Magnetic Effects using Javascript

В этом видео создается магнитный эффект для блока на CSS и JS.

👉 @seniorFront

Осмысленные беседы

👉 @seniorFront

Hover Effect

Параметры анимации задаются через JS при наведении.

👉 @seniorFront

Bounce Delay Loader

Оригинальный загрузчик, реализованный с использованием препроцессоров Haml и SCSS.

👉 @seniorFront

CSS Liquid Effects

В этом видео создается эффект жидкости на HTML, CSS и JS.

👉 @seniorFront

Cylinders Grid

Это компонент из библиотеки Three.js, реализованный на canvas.

👉 @seniorFront

Highest and Lowest

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

Примеры:

highAndLow("1 2 3 4 5");   // return "5 1"
highAndLow("1 2 -3 4 5");  // return "5 -3"
highAndLow("1 9 3 4 -5");  // return "9 -5"

👉 @seniorFront

Пишем идеальную mobile-first галерею

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

👉 @seniorFront

Какая есть важная особенность у pipe?

Это популярная концепция в программировании, особенно в функциональных языках и библиотеках вроде RxJS (в контексте реактивного программирования). Она используется для последовательного применения функций к данным.

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

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

Композиция
Вместо вложенных вызовов функций (когда результат одной функции передается в другую) pipe упрощает цепочку, делая её линейной.

Читаемость
Код становится проще для понимания, особенно если функций много.

Легкость модификации
Можно легко добавлять или удалять шаги в цепочке, не меняя структуру кода.

Как работает pipe?

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

Пример реализации простого pipe

const pipe = (...functions) => (input) => 
  functions.reduce((acc, fn) => fn(acc), input);

// Пример функций
const multiplyByTwo = (num) => num * 2;
const addThree = (num) => num + 3;
const square = (num) => num ** 2;

// Использование pipe
const processNumber = pipe(multiplyByTwo, addThree, square);

console.log(processNumber(5)); // ((5 * 2) + 3) ** 2 = 169

Использование в RxJS
В контексте RxJS pipe используется для работы с потоками данных, где через него можно передавать операторы, такие как map, filter, mergeMap и другие.

import { of } from 'rxjs';
import { map, filter } from 'rxjs/operators';

// Создаем поток данных
const numbers$ = of(1, 2, 3, 4, 5);

// Используем pipe для применения операторов
numbers$
  .pipe(
    filter((num) => num % 2 === 0), // Оставляем только четные
    map((num) => num * 10)          // Умножаем их на 10
  )
  .subscribe((result) => console.log(result)); 
// Вывод: 20, 40

👉 @seniorFront

CSS infinite scroll gallery

Бесконечная галерея картинок, анимированная в CSS. В JS реализован функционал перезапуска положения прокрутки при достижении определенной точки.

👉 @seniorFront

​Как стоит оценивать задачи, чтобы улучшить прогнозирование сроков?

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

Почему так происходит? Потому что абсолютные оценки в часах не работают. Они не учитывают неопределенности, возникающие в процессе работы:

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

Как же тогда планировать и прогнозировать сроки выполнения задач?

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

Как это сделать:
- Фиксируйте, когда задача была взята в работу и когда она реально была завершена (включая тестирование и релиз).
- Отслеживайте не только время разработки, но и задержки, связанные с ожиданием ответов, согласованиями и релизами.
- Разделите задачи по размеру (например, S, M, L, XL) и собирайте статистику по каждому типу.

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

- Story Points (по ряду Фибоначчи: 1, 2, 3, 5, 8 и так далее).
- Оценку в «футболках» (XS, S, M, L, XL).

Как это работает:
- Находим в бэклоге самую маленькую задачу, принимаем ее за 1 SP (или XS).
- Сравниваем другие задачи с ней и оцениваем их относительно друг друга.
- Планируем спринт и смотрим, сколько SP команда реально завершает за итерацию.
- Через 3–5 спринтов накапливается статистика, на которую можно опираться при планировании.

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

3. Использовать статистику выполнения прошлых спринтов
Если вы работаете по Scrum, можно анализировать, сколько Story Points команда выполняла в прошлых спринтах.

Как это сделать:
- Фиксируйте скорость команды (Velocity) — среднее количество выполненных SP за спринт.
- Учитывайте тенденции — если команда стабильно делает 30 SP за спринт, то планировать на следующий спринт 50 SP бессмысленно.
- Анализируйте вариативность — насколько часто сроки отклонялись от запланированных, какие были причины.

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

👉 @seniorFront

Сделай удобно: подборка UI/UX-кейсов из цифровых и нецифровых продуктов

Продолжаю изучать различные UI/UX/CX кейсы в мобильных приложениях, веб-сайтах и в реальном мире. Дизайнерам и менеджерам по продукту, чтобы вдохновиться и добавить в заметки.

Под катом: N26, Glovo, Flowwow, Intsargam.

👉 @seniorFront

Logo Factory

Свёрстано на HTML и SCSS. Функционал рисования лого, а также скачивание результата реализованы в JS.

👉 @seniorFront

Keyboard

В этом видео создается реалистичная клавиатура на CSS и чистом JS, которая отображает нажатые клавиши в данный момент.

👉 @seniorFront

Программист показывает своё решение:

👉 @seniorFront

Sticky Navigation

Свёрстано с использованием препроцессоров Pug и SCSS. Функционал плавной прокрутки реализован в JS.

👉 @seniorFront

Fluid Simulation With Your Text

Реализовано на canvas и чистом JS с использованием технологии WebGL

👉 @seniorFront