Тредик с фактами о фронтенд части (компиляция tech.hh.ru/about.html и интересных фактов): >>
Фронтенд делится на 2 стека: старый и новый. Старый это ванильный js + jQuery, на сервере html рендерится через xslt, на клиенте mustache. Новый стек — это почти классическое React-Redux приложение.
Стили пишем в less, используем АНБ подход для разграничения стилей АНБ — верстка независимыми блоками, одно из первый названий БЭМ, которое очень у нас прижилось и очень похоже на классический БЭМ без миксинов и с большим упором на блоки.
На новом стеке включен SSR везде. Миграция отдельная большая тема, о ней поговорим на следующий день
Есть UIToolkit — блоко. Работает на двух стеках и состоит более чем из 120 компонентов. Начиная от кнопок и заканчивая сложными компонентами древовидного выбора с тегами, поиском и т.д. Документирована либа на styleguidist, спасибо @iamsapegin за удобное и расширямое решение.
Кстати, на styleguidist документированы и легаси компоненты. Для написания примеров у нас используется кастомный рендер, который выглядит вот так:
Код транспайлится бабелем (тайпскрипта у нас пока нет). Используем в том числе такие штуки как optional chainig: github.com/tc39/proposal-… и async-await
Есть самописные бабель плагины. Некоторые могут быть полезны всем, некоторые специфичны: github.com/hhru?utf8=%E2%…
Код автоматически проверяем eslint github.com/hhru/eslint-co… — наш конфиг. Для стилей используем stylelint. Prettier настроен на js, css, less, json, md
Все фронтендеры пишут прослойку на питоне — это сервис, который выполняет роль API Gateway. Получить запрос пользователя, сделать 100500 запросов на бекенды (обычно параллельно), собрать воедино и отдать на рендер xslt или React.
Код в прослойке очень простой, веб-сервер c открытым кодом: github.com/hhru/frontik
Юнит-тесты. Их пишем на новом стеке обязательно. Кроме юнит-тестов есть более 8000 сьютов автотестов. Автотесты прогоняются при тестировании задачи, перед выкладкой релиза. Все автотесты проходят примерно за час.
В каждом PR мы сделали индикацию code-coverage в зависимости от base branch. Основное правило — желательно, чтобы покрытие юнит-тестами не уменьшалось с твоей задачей. Вот так выглядит отчет, когда покрытие не изменилось:
Если стало меньше и если увеличилось:
Fun Fact: такой простой прием позволил заметно повысить code coverage
У каждого разработчика, тестировщика в компании есть отдельная виртуалка, со всеми сервисами. Вся разработка сводится к синку кода с виртуалкой. За счет чего у тебя всегда под рукой все нужные сервисы.
Накатка веток, запуск тестов, обновление стенда — все автоматизированно. Например, у меня в 8 утра всегда происходит обновление моего стенда. Я приезжаю на работу — у меня все свежее.