Словарь айти-сленга: разбираем самые популярные слова

На дейлике обсуждают баги, просят апрув у тимлида и обещают задеплоить к вечеру. Если вы киваете, но не до конца понимаете, о чем речь, — эта статья для вас. Объясняем IT-сленг и показываем, когда его используют.

• Базовые понятия
• Роли и участники
• Инструменты и технологии
• Рабочие процессы и операции
• Частые вопросы

Базовые понятия

Начнем с простых, но часто используемых терминов.

Релиз

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

Виды релизов:

• Major — крупное обновление с ощутимыми изменениями. Например, полностью новый интерфейс или запуск мобильной версии.
• Minor — небольшие улучшения: новый фильтр в каталоге или ускорение работы какого-то процесса.
• Hotfix (или хотфикс) — срочное исправление критической ошибки. Делают вне обычного графика.

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

Фича 

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

Фича начинается с идеи и ресерча, потом попадает в бэклог, проходит разработку и тестирование, а затем входит в релиз. 

Баг

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

Когда ошибка серьезная, выпускают хотфикс. Пример: «нашли баг в оплате — у пользователей не проходит транзакция». Если нет, баг попадает в план работ и закрывается в одном из спринтов. 

Бэклог

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

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

Бэкап 

Резервная копия данных. Нужна, чтобы восстановить систему после сбоя. Создают перед крупными обновлениями или миграциями (переносом данных, приложений или всей ИТ‑инфраструктуры из одной среды в другую). 

Виды бэкапов:

• Полный — копируют всю информацию.
• Инкрементальный — сохраняют только изменения с момента последнего обновления.
• Дифференциальный — копируют все новые данные с момента последнего полного бэкапа.
• Синтетический — объединяет предыдущий полный бэкап с последующими инкрементными.

Деплой 

Размещение кода на сервере, после чего изменения становятся доступны пользователям. Иногда говорят «деплоить» — выложить или развернуть код на сервере. Деплой может быть автоматизированным или ручным, с дополнительными проверками и мониторингом — особенно если релиз крупный.

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

Пример: «команда задеплоила новую систему оплаты в понедельник» или «деплой прошел, сервис поднялся».

Ресерч 

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

Апрув 

Согласование решения. Его дает тимлид, заказчик или продакт. Без апрува не запускают релиз и не начинают крупные работы.

Дейлик 

Короткая ежедневная встреча команды — она же планерка. Каждый сотрудник кратко отвечает на два вопроса: «Что сделал?» и «Что буду делать?». Если дейлик превращается в часовую встречу с обсуждением всего подряд — это уже просто совещание.

Бэкэнд 

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

Роли и участники

Кого можно встретить в команде.

Тимлид 

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

Джун, мидл и сеньор

Это уровни специалистов. Они показывают степень самостоятельности и зону ответственности. От уровня зависят задачи и зарплата.

• Джун — начинающий специалист с минимальными знаниями. Решает простые таски под контролем более опытных коллег. Обычно берет типовые или изолированные задачи, где меньше риска повлиять на систему целиком.
• Мидл — самостоятельный, опытный работник. Оценивает задачи, предлагает решения и доводит их до результата без постоянного контроля. Закрывает основной объем работы команды.
• Сеньор — опытный специалист высшего уровня. Отвечает не только за свою задачу, но и за результаты команды. Принимает решения, участвует в сложных обсуждениях, обучает младших коллег.

Дезигнер 

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

Продакт-менеджер

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

Проджект-менеджер

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

Читать про спринты и легаси — полезно. Но чтобы уверенно чувствовать себя в команде, нужно поработать с этим на практике. Если вопрос в деньгах, разбейте стоимость обучения на части с помощью карты «Халва». Платите постепенно и получайте кешбэк за учебу у партнеров.

Инструменты и технологии

Переходим к работе.

Движок 

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

Движок задает границы проекта. На устаревшем движке любые нестандартные решения будут затратными и рискованными.

Фреймворк

Набор инструментов и правил разработки. Ускоряет работу и задает структуру проекта: как организованы файлы, обрабатываются запросы, взаимодействуют модули или подключаются базы данных.

Стек 

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

Конфиг 

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

Рабочие процессы и операции

Слова из повседневной разработки.

Мержить 

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

Откатить 

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

Синк

Синхронизация. Термин используют в двух смыслах. Первый — технический: синхронизация данных между сервисами или средами. Например: «Нужно синкануть базу с тестовой среды». Второй — организационный: короткая встреча для контроля статуса задач. Пример: «Давайте сделаем синк по релизу».

Спринт

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

Дебажить 

Искать причину ошибки и устранять ее. Пример: «полдня дебажили падение сервиса».

Холд

Временная остановка задачи или процесса. Причины разные: нет апрува, не готов ресерч, изменились приоритеты. Например: «Ставим задачу на холд до решения заказчика».

Фидбэк

Обратная связь, отзыв. Это могут быть комментарии к интерфейсу, замечания по коду или реакция пользователя на новую фичу. Пример: «Получили негативный фидбэк после релиза».

Итерация

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

Ворнинг

Предупреждение системы. Это не ошибка, а сигнал: что-то может работать некорректно или нестабильно. Игнорировать ворнинги рискованно — они часто сигнализируют о багах.

Легаси

Устаревший код или система, которые продолжают работать, но плохо поддерживаются.

Костыль

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

Примеры: «поставили костыль, чтобы релиз не сорвать» или «пора убрать старые костыли».

Частые вопросы

Рассказываем то, что не упомянули в статье.

Чем отличается деплой от релиза?

Деплой — это технический процесс выкладки кода на сервер. Релиз — запуск версии продукта. Иногда деплой делают несколько раз, а релиз объявляют один.

Почему разработчики говорят на «своем языке»?

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

К тому же так быстрее. Вместо «выпустили срочное внеплановое обновление с исправлением ошибки» проще сказать «выкатили еще один релиз с хотфиксом». 

Что такое бэкап и нужен ли он небольшим проектам?

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

Нужно ли разбираться в IT-сленге, если я не разработчик?

Да, если вы взаимодействуете с IT-командой, будь то постановка задач, прием работ или согласование бюджета. Когда все говорят на «одном языке», работа идет быстро и без ошибок. 

Если я HR или рекрутер, мне нужны термины?

Да, чтобы общаться с кандидатами и командой. Необязательно знать все термины, но вы должны иметь общее представление о специфике работы в этой области.