Здесь будет тред, о том, как организован технический департамент HeadHunter (большими мазками) >>>
У нас нас есть страница на tech.hh.ru/about.html, где описано достаточно подробно все, какие технологии мы используем, как разрабатываем задачи. Информации много, поэтому выделю наиболее интересные моменты.
Технический департамент на текущий момент — это более 130 человек и 25 команд. Каждая команда — отдельный unit, который может решить задачу от начала до конца.
Поэтому стандартная конфигурация команды это 1 фронтенд-разработчик, 1 бекенд, 1 тестировщик и 1 тимлид. В зависимости от задач команды конфигурация может отличаться
Владение кодом общее. Поэтому если команде, которая занимается работодательскими фичами, нужно добавить что-то в поиск, она не ждет команду поиска, а идет и добавляет сама.
Команды разбиваются по своим ролям: работодательские фичи, соискательские сервисы, поиск, реклама, команды сайд-проектов. Команд, которые занимаются, например, работодательскими фичами может быть несколько.
Бывает так, что какая-то команда больше занимается определенной частью возможностей, например, созданием вакансий. Здесь открывается огромный мир задач. Шаблоны вакансий, типы, настройки, адреса офисов, аналитика — куча всего, что может быть переплетено с другими фичами сайта.
У каждой команды есть product owner, с которым команда прорабатывает задачи. Команда участвует в проработке задач полноценно, а не только как технический консультант.
Большинство задач выпускаем под AБ-тестами. Обычно на проде одновременно включено десятки (а то и сотни) тестов. Есть собственная система аналитики и подсчета метрик.
Полезная-интересная штука: кроме бизнес-задач у нас есть понятие "технического налога" — это термин похож на техдолг, включает в себя задачи на рефакторинг, улучшение кодовой базы, переезд на новые технологии, упрощение потока данных и т.д.
Более того, есть соглашение, что 30% времени работы команды могут тратить на налог.
К предыдущему пункту — еще более хорошая новость, что договоренность про 30% соблюдается.
Код храним на Github, ревьювим код через pull request. Коротко про ревью — любой может участвовать, должен быть один ответственный ревьюер. В идеале ревьюить код должен человек, которому эта часть ближе всего
Релизы ежедневные. Сегодня сделал \ протестировал задачу — можно сегодня собрать релиз или завтра она автоматически попадет в релиз дня.
Самих релизов в день может быть много. Очень много. Они могут быть большими. Пару недель назад было 4 релиза фронтенд части основного сайта в один день, в одном из них выходило около 20 задач.
Это не считая остальных сервисов, которых у нас много (так как идем в стороу микро-сервисной архитектуры).
Никита Мостовой