Чистая архитектура фронтенд приложений

За свою карьеру я встречал достаточно много проектов, крупных и малых, которые страдали от огромной и запутанной кодовой базы с высоким уровнем зацепления и малой связностью, непонятной структурой, в которую весьма сложно погрузиться (на онбродинг нового сотрудника может уходить до трех месяцев) и большим количеством непонятных и громоздких компонентов, которые являются god object'ами. Стоит ли говорить, что у таких проектов имеются большие проблемы с поддержкой и развитием.

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

👉 @seniorFront

​Атрибут autofocus

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

Пример

<input name="name" autofocus>

Атрибут autofocus булевый: его присутствие означает true, а отсутствие — false. Чаще его применяют к интерактивным тегам, например, <input>, <button>, <select>, <textarea>.

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

Обратите внимание, что автофокус не будет применён к элементам <input> с типом hidden, потому что скрытые поля не могут получать фокус.

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

👉 @seniorFront

Exploring UI Animation

Свёрстано на HTML и SCSS. Логика работы реализована в JS. Анимировано библиотекой TweenMax.

👉 @seniorFront

​Что творится с работой в IT в 2025?

Пару лет назад в компании выстраивались в очередь за кадрами, а рекрутеры искали сотрудников даже в сервисах знакомств. Сейчас страсти поутихли. Высокие ставки ЦБ заставили компании пересмотреть аппетиты: бизнес начал считать каждую копейку, реолаканты вернулись, новичков без опыта после курсов прибавилось. И как же изменения повлияли на рынок?

- Рост зп замедлился — новичкам теперь не светит прибавка, а в некоторых местах вилки и вовсе урезали.
- Джунам теперь нужен опыт — если раньше хватало теоретических знаний, сейчас требуют, чтобы ты уже поработал на реальных проектах.
- Плюшки порезали — бесплатные обеды, спортзалы и психологи теперь только в крупных компаниях, но и за эти привилегии еще нужно побороться.
- Глобальные сокращения — ИИ составляет конкуренцию действующим спецам, больше не нужна команда из 10 человек, достаточно 2-3, которые направляют новые технологии.

Но кадров всё равно не хватает!
На новые проекты собирают ресурсы из переполненных команд и не набирают новых сотрудников. Только теперь нужны не просто «айтишники», а профи в узких областях. Например, в защите данных нехватка — 20%, а в разработке под отечественные ПО для госструктур— 30%. Компании перестали брать «наугад» — нужен человек, который быстро подхватит все задачи.

А что с зарплатами и мировыми трендами?
- Мидлы в минусе — их зарплаты ниже, чем пару лет назад.
- Сеньоры выжимают максимум из бонусов — фиксированные ставки почти не растут.
- Джуны в тисках конкуренции — на одну вакансию приходится 200+ откликов (раньше было 20-30).

В мире тоже не сладко: Amazon, Microsoft и другие гиганты уволили десятки тысяч сотрудников. В России же проблема другая — катастрофически не хватает тех, кто разбирается в нашем софте (российские ОС, базы данных).

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

👉 @seniorFront

Скетч системного дизайна: как одна схема решает множество проблем на старте проекта

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

👉 @seniorFront

Flipping Parallax Card

Создано и анимировано с использованием препроцессоров Pug и Stylus. Логика переключения типа анимации реализована в JS.

👉 @seniorFront

Border Animation Effects

В этом видео создаётся анимированная граница блока на HTML и CSS.

👉 @seniorFront

Тебя вообще кто-то спрашивал?

👉 @seniorFront

Minimal Clothing Catalogue

Оригинальные раскрывающиеся карточки, реализованные на HTML и SCSS.

👉 @seniorFront

Curved Texts

Это анимированные SVG картинки. Анимация запускается через JS.

👉 @seniorFront

Awesome Image Effects

В этом видео анимируется картинка, распадающаяся на частицы на CSS и JS

👉 @seniorFront

Perspective Menu

Меню, анимируемые при наведении, созданные с использованием препроцессоров Pug и Stylus.

👉 @seniorFront

Not very secure

В этом примере вам необходимо проверить, является ли строка ввода пользователя буквенно-цифровой.

Строка имеет следующие условия, чтобы быть буквенно-цифровой:
- Должен быть хотя бы один символ ( "" недопустимо)
- Разрешенными символами являются прописные/строчные латинские буквы и цифры от 0 до 9
- Никаких пробелов или подчеркиваний

Пример:

alphanumeric("Mazinkaiser")  //  true
alphanumeric("hello world_")  //  false
alphanumeric("PassW0rd")  //  true
alphanumeric("     ")  //  false

Самозанятый или ИП: как айтишнику выбрать форму работы в 2025

Айтишник работает удалённо. Пишет код, собирает дашборды, настраивает DevOps или консультирует по безопасности. Клиенты платят. Деньги капают. И вот тут возникает вопрос: оформляться как самозанятый или регистрировать ИП?

Однозначного ответа нет — и это хорошо. Потому что выбор формы работы в 2025-м стал не просто техническим, а стратегическим. Он зависит не только от цифр, но и от целей.

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

👉 @seniorFront

Что такое Dependency Injection (DI)?

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

Принципы
- Инверсия управления (Inversion of Control, IoC)
Принцип, согласно которому объект делегирует управление своими зависимостями внешнему источнику.
- Внедрение зависимостей (Dependency Injection)
Конкретная реализация инверсии управления, при которой зависимости передаются объекту через конструктор, методы или свойства.

Способы внедрения зависимостей

- Внедрение через конструктор
Зависимости передаются объекту через параметры его конструктора.

interface Repository {
  doSomething(): void;
}

class ConcreteRepository implements Repository {
  doSomething() {
    console.log("Repository is doing something!");
  }
}

class Service {
  private readonly repository: Repository;

  constructor(repository: Repository) {
    this.repository = repository;
  }

  performAction() {
    this.repository.doSomething();
  }
}

// Пример использования
const repository = new ConcreteRepository();
const service = new Service(repository);
service.performAction(); // Выведет: Repository is doing something!

- Внедрение через сеттеры
Зависимости передаются объекту через методы-сеттеры после его создания.

interface Repository {
  doSomething(): void;
}

class ConcreteRepository implements Repository {
  doSomething() {
    console.log("Repository is doing something!");
  }
}

class Service {
  private repository: Repository | undefined;

  setRepository(repository: Repository) {
    this.repository = repository;
  }

  performAction() {
    if (!this.repository) {
      throw new Error("Repository is not set");
    }
    this.repository.doSomething();
  }
}

// Пример использования
const repository = new ConcreteRepository();
const service = new Service();
service.setRepository(repository);
service.performAction(); // Выведет: Repository is doing something!

- Внедрение через интерфейсы
Зависимости передаются объекту через методы, определённые в интерфейсах.

interface IRepository {
  doSomething(): void;
}

class Repository implements IRepository {
  doSomething() {
    console.log("Doing something...");
  }
}

class Service {
  private repository: IRepository;

  constructor(repository: IRepository) {
    this.repository = repository;
  }

  performAction() {
    this.repository.doSomething();
  }
}

// Пример использования
const repository = new Repository();
const service = new Service(repository);
service.performAction(); // Выведет: Doing something...

Плюсы
- Улучшение тестируемости
Код становится более модульным и тестируемым, так как зависимости можно легко заменять на моки или стабы в тестах.

- Улучшение поддерживаемости
Уменьшается связность кода, что упрощает его поддержку и модификацию.

- Улучшение гибкости
Легче менять реализации зависимостей, не изменяя код, который их использует.

- Явное указание зависимостей
Зависимости объектов становятся явными, что улучшает понимание кода.

Минусы
- Усложнение кода
Внедрение DI может усложнить код, особенно если используется слишком много уровней абстракции.

- Кривая обучения
Понимание и правильное использование DI может потребовать времени и обучения, особенно для разработчиков, незнакомых с паттерном.

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

👉 @seniorFront

Responsive Vertical Slider

Логика работы слайдера реализована библиотекой Swiper. Анимировано в CSS.

👉 @seniorFront

​Побеждаем алгоритмическую секцию на собесах!

Делюсь опытом прохождения алгоритмических собеседований — сложного, но проходимого этапа! Вот ключевые моменты:

Почему это сложно?

- Время ограничено: ~20 минут на чтение задачи, код и проверку.
- Писать код нужно под контролем, без автодополнения, с условной подсветкой синтаксиса (например, в Yandex Code).
- Нужно оставаться спокойным и чётко объяснять свои действия.

Как готовиться и побеждать?

1. Читай и узнавай задачу: практика на Leetcode и Yandex.Coderun поможет "узнавать" типовые алгоритмы (два указателя, рекурсия, хэш-мапы, строки).
2. Проговори решение: перед кодом озвучь логику, чтобы избежать ошибок "на ходу".
3. Учти краевые случаи: пустой массив, один элемент, отрицательные числа, итерации в начале/конце. Пиши их в комментариях.
4. Пиши и комментируй: тренируйся писать код, объясняя каждую строку.
5. Проверяй: прогоняй код на тестовых данных, фиксируй промежуточные результаты в комментариях.
6. Знай сложность: линейная, квадратичная или логарифмическая — будь готов ответить по времени и памяти.

Главный секрет — насмотренность. Решай задачи (easy/medium) с таймером, без автодополнения, комментируя вслух. Это снизит стресс на собесе.

Верь в себя, и всё получится!

👉 @seniorFront

Почему в интерфейсах со сложной логикой недостаточно показать макеты в Figma?

В принципе, в меме всё честно. Но я всё же решила объяснить, почему не кидаю ссылку на Figma по первому запросу.

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

👉 @seniorFront

To-do list

Оригинальный TO_DO list, на чистом JS. Стилизованный в SCSS.

👉 @seniorFront

Navigation Tabs with Sliding Menu Indicator

В этом видео создаётся анимированное навигационное меню на чистом CSS.

👉 @seniorFront