Где работать в ИТ в 2021: Sports.ru
Сегодня в рубрике «Где работать в ИТ» рассказываем вам про Sports.ru — компанию, которая развивает крупнейший российский спортивный интернет-портал и делает ещё много чего интересного. На Хабр Карьере сотрудники оценили её работодательские качества на 4,76 из пяти, и это принесло ей седьмое место в нашем рейтинге этого года среди компаний до 1000 человек.
О найме, условиях работы, технологическом стэке и процессах в Sports.ru нам подробно рассказали технический директор Павел Пигалев и эйчар-директор Юлия Аверина.
Оценивайте своих работодателей на Хабр Карьере, чтобы поделиться мнением с теми, кто сейчас ищет работу в ИТ!
→ оценить работодателя
Навигация по статье
О компании
Sports.ru — это не просто крупное российское медиа о спорте, это высоконагруженная технологическая платформа, которая позволяет пользователям читать тексты, блоги и новости, следить за матчами и участвовать в жизни спортивного сообщества.
Кроме развития портала, компания выпускает подкасты, ведет шоу на YouTube и развивает два новых направления: cyber.sports.ru (проект про киберспорт и видеоигры) и «Здоровье» (медиа о ЗОЖ и восстановлении после травм). Есть и B2B-направление: рекламная сеть United и агентство спортивного маркетинга Fever Pitch, которое помогает брендам выстраивать отношения с болельщиками.
Как работодателя Спортс.ру ценят за комфортные условия работы и за отличные отношения в команде — как с коллегами, так и с руководителями. Подробную оценку Спортс.ру и комментарии сотрудников читайте в профиле компании на Хабр Карьере.
Оценка Sports.ru на Хабр Карьере в 2021 году
Об условиях работы
Какой в вашей компании сложился рабочий график и какое отношение к переработкам?
Павел: У нас, как и в большинстве IT-компаний, нет единого начала и окончания рабочего дня. Внутри разработки есть договоренность, что время между 12 и 17 — это время, когда все на связи. Остальную часть рабочего дня ребята могут сдвигать так, как им удобно.
Юлия: Эту гибкость графиков мы учитываем и при организации всех командных и общекорпоративных встреч и стендапов: не назначаем их на раннее утро или совсем поздний вечер.
Павел: Из сложившейся культуры хочется еще отметить такую крутую штуку, как гугл-календарь, по которому мы все стараемся жить. Все видят календари друг друга, все встречи ставятся через календари, там же можно заранее пометить то время, когда ты будешь отсутствовать или когда ты не хотел бы, чтобы тебя трогали. Очень добавляет прозрачности и организованности.
Переработки — это не норма. Необходимость в переработках значит, что неправильно устроено планирование. Конечно, бывает всякое, и в редких случаях перед большими спортивными турнирами у нас могут быть несколько жарких недель.
Какие бытовые условия ждут нового сотрудника на рабочем месте?
Юлия: У нас просторный и светлый офис в самом центре Москвы на 1500 м2, который, несмотря на глобальную удаленку, пользуется спросом у сотрудников. В 2018 году мы взяли голую бетонную коробку на Большой Татарской из-за высоких потолков, огромных окон и максимально удачного расположения и не пожалели.
Конечно, изначальный ремонт отнял много времени, сил и ресурсов, но он позволил создать помещение, которое на тот момент подходило по функционалу именно нам. Остановили свой выбор на опенспейсной планировке, так как она позволяет быть более гибкими в плане организации рассадки команд. Есть немного кабинетов, десяток переговорок и комнат, где можно поработать в тишине, есть игровая с кикером и PS и столовая со всякими овощами, фруктами, орехами и шоколадом.
После перехода части команды на гибридный формат работы у нас появилось намного больше свободного пространства, и стало понятно, что нам необходимо либо основательно перестраивать текущее пространство, либо искать новое. Поэтому сейчас мы активно рассматриваем новые помещения и фантазируем над будущим дизайном.
Павел: По технике для сотрудников у нас все просто: предоставляем полный набор, необходимый для работы. Обычно это ноутбук (Mac / Windows / Linux), один или два монитора и что-то из периферии, если есть запрос.
Есть ли возможность удаленной работы?
Павел: Пандемия заставила нас пересмотреть подход к офисной работе. У нас все еще остается достаточно людей, которые ценят офис и стабильно в него ходят, но многим понравилась и удаленная работа. Так что теперь в Sports.ru есть три типа сотрудников:
одни регулярно ходят в офис,
другие большую часть времени работают из дома, но иногда приходят в офис,
третьи постоянно работают удаленно.
Под эти новые реалии мы пересмотрели и устройство рабочих зон. У нас появились постоянные места, которые закреплены за теми, кто часто ходит в офис, и «гибкие» рабочие места — это ни за кем не закрепленные столы, оборудованные всем необходимым. Важно, что при этом мы сохранили зоны команд, чтобы ребята, которые приходят редко, могли садиться не куда-то, а именно к своей команде.
Сейчас удаленка для нас так же привычна, как раньше работа из офиса.
Какой социальный пакет получают сотрудники?
Павел: У нас достаточно всяких плюшек разного масштаба. Самая крупная — это ДМС со стоматологией. Причем, она распространяется с первого дня и на сотрудников не только из Москвы. Помимо этого у нас есть компенсация обучения: на каждого сотрудника выделена сумма, которую он может потратить на личное обучение по собственному желанию. Главное, чтобы оно имело отношение к работе.
Посещение конференций сюда не включается, это идет отдельно. В компании лучше всего прижился формат онлайн-просмотра конференций командой из офиса, но последнее время (возможно, из-за того, что в пандемию все соскучились по нормальной жизни) думаем чаще ходить на конференции лично.
Юлия: Мы постоянно пересматриваем наш соцпакет, стараясь сделать его максимально полезным для сотрудников. Например, ДМС со стоматологией у нас была уже давно, но она не была рассчитана на удаленных сотрудников, и ей можно было начинать пользоваться только после испытательного срока. А с мая этого года мы сделали страховку доступной с первого рабочего дня и ввели компенсации сотрудникам не из Москвы на самостоятельную покупку ДМС.
Помимо этого у нас есть компенсация занятий английским и фитнеса. Еще мы организовали занятия футболом, волейболом и баскетболом. Для части тренировок даже приглашаем тренера, так что все серьезно :) Футбольная команда почти круглый год участвует в каких-то турнирах и лигах, ведет свой инстаграм — в общем, настоящее полноценное сообщество.
Павел: И отдельно про самый необычный пункт, который я бы тоже отнес к соцпакету. По причине болезни или каких-то других особых личных обстоятельств всегда можно взять 1–2 дня на восстановление или решение дел без какого-либо оформления этих дней. Мне кажется, что это правило очень хорошо показывает уровень доверия компании к своим сотрудникам!
Какие бонусы, премии и компенсации предусмотрены в компании?
Юлия: Долгое время премии у нас были предусмотрены только за работу над коммерческими (рекламными) проектами. Для остальных отделов премии могли быть только за какие-то сверхдостижения. Например, когда Sports.ru был заблокирован в Беларуси один из наших девопсов по своей инициативе начал искать варианты решения этой проблемы. Пробовал, экспериментировал и в итоге нашел выход, организовал ребят и довел до релиза то, что сделало наш сайт доступным в РБ без каких-либо дополнительных действий со стороны пользователей.
Еще интересный кейс был с ботом для команды маркетинга. Наш CMO закинул в чат разработки просьбу помочь с написанием бота, один из коллег откликнулся и за пару вечеров сделал рабочее решение, не сдвигая при этом сроки спринта.
Сейчас мы разрабатываем систему полугодовых премий, размер которых будет зависеть от результатов performance review, в котором подобные сверхусилия будут учитываться наравне с другими факторами.
Какие есть перспективы для образования и личного развития у сотрудников?
Юлия: Нам нравится думать о себе как о компании-школе, в которой опытные наставники дают коллегам столько информации, сколько они смогут усвоить, и столько ответственности, сколько они смогут унести.
Почти все текущие топ-менеджеры выросли внутри компании. Марк Тен за семь лет прошел в компании путь от джуниор продакт менеджера до CEO. Сергей Лопатенко за три года работы стал CMO, хотя пришел совсем начинающим маркетологом. Влад Воронин начал писать на сайт в 2010-м, когда ему было 17 лет, и очень быстро стал одним из важнейших людей в редакции, а в 2020-м возглавил ее.
Если необходима внешняя экспертиза, стараемся нанимать консультантов, чтобы развивать людей внутри, а не просто закрывать потребность готовым специалистом снаружи.
Сотрудникам, которые защищают идеи новых проектов, помогаем их лидировать. Так, например, в Sports.ru появилось нетипичное для нас направление о здоровом образе жизни и тренировках, хотя наш основной фокус — спорт высших достижений.
Павел: Два раза в год у нас проводятся performance review. Для подготовки к нему м мы детально разбираем работу сотрудников, собираем по всем коллегам обратную связь, и в итоге формируем полноценный документ, не только с оценкой прошедшего периода, но и с целями и ожиданиями по дальнейшему развитию. Все эти цели и ожидания составляются руководителем вместе с сотрудником, поэтому они всегда валидны. Такой формат сильно уменьшает вероятность стояния на месте.
О процессе найма
Во сколько этапов проходит найм и что на них ожидает соискателя?
Юлия: Мы — достаточно оперативные ребята, и процесс найма тоже не любим растягивать. Для большинства вакансий у нас предполагается три стандартных этапа: HR-скрининг, техническое интервью и финальная встреча. Если у кандидата нет жестких ограничений по времени интервью, то все эти этапы укладываются в неделю, максимум две.
Павел: Найм в разработку проходит в три этапа:
Общение с эйчаром — первичный созвон-знакомство, несколько коротких вопросов по опыту и ожиданиям кандидата и рассказ про компанию и вакансию.
Техническическое интервью с потенциальным руководителем — на нем мы сначала детальнее общаемся по опыту кандидата, а после этого идет техническая часть, которая состоит из нескольких задачек и вопросов. Мы стараемся обходить стороной общие теоретические вопросы, у нас все ближе к практике, нам важно в первую очередь понять, как кандидат думает, и примерно оценить его текущие навыки. После технической части рассказываем о компании и отвечаем на вопросы кандидата.
Финальное интервью с CTO и HRD — скорее даже разговор, а не интервью. На этом этапе не будет задачек, просто еще раз обсудим опыт, возможно, детальнее затронув некоторые интересные кейсы. Если очень грубо, то мы финально пытаемся понять, насколько друг другу подходим, сходимся ли по ожиданиям. Говорим, не украшая. Нам важно, чтобы кандидат точно понимал, куда идет и с чем будет работать.
Даете ли вы тестовое задание кандидатам? Как оно устроено?
Павел: Если говорить про разработку, то нет, тестовых заданий у нас нет. Нам в первую очередь важны soft-skills. Мы верим, что при необходимости hard-skills можно подтянуть.
Юлия: Тестовое задание — неоднозначный инструмент. Мы это понимаем и поэтому в IT-найме его совсем не используем. С помощью подходящих вопросов и задачек можно понять не только правильно или неправильно кандидат что-то делает, но и как мыслит в процессе, что учитывает, задает ли вопросы. Мы считаем, что неумение думать, задавать вопросы и слышать ответы — гораздо более яркий маркер человека, с которым мы не сработаемся, чем просто неверно или неоптимально решенное тестовое.
Как отличается подход к найму в зависимости от позиции и стека?
Павел: Идеологически подход не меняется. Меняются только люди на этапах и технические вопросы на техническом интервью :) В остальном формат кажется нам универсальным.
Какая фраза от кандидата на собеседовании точно заставит вас выкинуть его резюме?
Павел: Уверен, что набор таких фраз есть у наших рекрутеров, так что до технического этапа доходят те, кто не будет бросаться какими-то подобными фразами. Поэтому не могу вспомнить ничего подобного. Да и любую фразу стоит рассматривать в контексте. Бывает, что стоит задать пару уточняющих вопросов, чтобы изначально отталкивающая фраза в итоге приобрела совершенно другой смысл и стала более понятна.
Наверно, тут уместно было бы сказать про смущающие факторы. К таким можно отнести, например, исключительно денежную мотивацию. Понятно, что мало кто готов работать за интерес и всем нужны деньги. Но смущает, когда кроме денег кандидату особо не важны ни проект, ни команда, ни технологии. Есть большая вероятность, что нам с таким кандидатом не по пути. Тем не менее мы обязательно доведем интервью до конца, чтобы собрать полную картину, и только после этого будем принимать решение.
Юлия: «Это не моя зона ответственности» или «Мне за это не платят». Мы искренне любим спорт, а значит не только прославляем его героев, но и давим на болевые точки, указываем на недостатки и пытаемся изменить то, что нам не нравится. К своей работе мы относимся точно так же: если «спортсовый» сотрудник видит, что что-то работает не так, как надо, он не отмалчивается, а рассказывает о проблеме или решает ее сам, если для этого есть возможности.
«Если видишь ошибку, не проходи мимо» — простое правило, которое работало, когда в компании были десятки человек, и продолжает работать, когда счет пошел на сотни.
Кого последнего вы уволили и почему?
Павел: Начну с того, что увольнения у нас — это крайне редкая история, потому что мы очень тщательно ищем, пытаясь в команду пропустить только тех, кто подходит нам и кому подходим мы.
Но случаются и ошибки, которые мы стараемся обнаружить как можно раньше. Последнее увольнение сотрудника по моей инициативе было в декабре 2020. Это был недавно вышедший к нам бэкенд-разработчик, который отработал только две недели. Сотрудник не проявлял совершенно никакого рвения, не погружался в работу, стопорился на простейших задачах, отказываясь от помощи. Я и тимлид провели с ним встречу, где еще раз проговорили ожидания и имеющиеся проблемы. Спустя несколько дней после разговора был тот же нулевой прогресс. Так что мы пообщались заново и договорились, что он нас покинет.
Отмечу, что никто не ждет обязательного решения задач из бэклога в первые же дни работы. Мы стараемся очень плавно и аккуратно погружать новых сотрудников в работу, не ожидая ни от кого молниеносных результатов.
Как происходит онбординг нового сотрудника?
Павел: Каждому новому сотруднику выделяется куратор. В абсолютном большинстве случаев куратором становится не тимлид, чтобы у нового сотрудника с первого дня формировались и другие виды командных связей.
Также каждому новичку тимлид готовит адаптационный лист с ожиданиями на испытательный срок. Это список целей по методике SMART — цель, описание планируемого результата и примерный срок выполнения. Может звучать как-то слишком формально, но на деле этот список сильно упрощает погружение, потому что ты понимаешь, чего именно от тебя ждут. В первые дни обязательно проводится встреча, где этот адаптационный лист обсуждается с новым сотрудником и его куратором. Мы всегда готовы подвинуть сроки или пересмотреть какие-то цели, но на практике этого ни разу не требовалось.
Сотрудник с первого же дня добавляется во все командные активности и встречи. Да, первое время может быть ничего не понятно, но это быстро проходит. А такой подход ускоряет погружение новичка в работу.
Помимо этого тимлид ставит обязательные тет-а-теты с сотрудником. Первое время они могут быть чуть ли не ежедневными, но в итоге все приходит к стандарту — раз в две недели.
О команде
Какая методология разработки у вас используется и почему?
Павел: Религиозных убеждений в единственно верной методологии у нас нет. Всегда готовы пересмотреть процессы, что-то выкинуть, заменить или перепридумать. Главное, чтобы поставленные перед этой практикой задачи решались проще и эффективнее. А так у нас, как у всех — некая смесь Scrum, немного Kanban и собственных велосипедов.
В продуктовой разработке Sports.ru мы живем недельными спринтами. Спринты набиваются декомпозированными задачами, отталкиваясь от приоритизированных бэклога продукта и технического долга.
У команд есть ежедневные короткие стендапы, на которых проговариваются свершения, планы и проблемы каждого. Также команды стабильно собираются, чтобы оценить задачи. Оценка происходит по практике scrum-poker. Это идеальная практика, которая позволяет не только получить более объективную оценку, но и в ряде случаев дополнить задачу вводными или вариантами решения, а также повысить экспертизу в продукте и заранее понять, какие задачи планируются.
Мы регулярно проводим ретроспективы спринтов, это нам помогает вовремя отследить проблемы, которые мешают работе. Если можем, то сразу назначаем ответственных за исправление или поиск решений. Конечно, ретро — это место не только про обсуждение проблем, на этих встречах мы обязательно отмечаем и успехи команд.
Но не у всех команд такие процессы. Есть ребята, которые ближе всего работают с рекламой и спецпроектами, там многое зависит от внешних заказчиков, и не всегда можно точно спланировать работу. Так что тут мы применяем Kanban.
Также у нас есть сугубо технические команды, где, наоборот, планы более стабильны и можно увеличивать длину спринта.
Каковы размеры и структуры команд?
Павел: Разработка Sports.ru делится в первую очередь по технологическим направлениям — backend, frontend, QA, devops. Далее деление идет на команды. Например, в бэкенде у нас сейчас три команды: основной продукт, статистические сервисы и платформа. При этом команды между технологических направлений плотно друг с другом работают. Достигается это единым продуктовым бэклогом и общими планированиями.
Размеры команд различаются. Продуктовые команды самые большие, в них до десяти человек. В технических командах людей меньше — около пяти. Сейчас в разработке Sports.ru около 50 человек. И мы активно растем, что неизбежно будет вести к формированию новых команд и в некоторых случаях к разделению текущих.
По каким критериям вы разбиваете разработчиков на джунов, мидлов и синьоров?
Павел: Конечно, в первую очередь мы отталкиваемся от опыта сотрудника и его технических навыков. Но большой опыт и сильные харды не обязательно означают, что сотрудник синьор, как и наоборот. Важны еще и soft-skills: уровень ответственности, проактивность, навыки коммуникации и так далее.
Если попытаться объяснить очень грубо, то деление такое:
Junior — умеет выполнять задачу, но только по отлично описанной и уже декомпозированной инструкции.
Middle — по хорошему продуктовому ТЗ может сам декомпозировать и выполнить задачу.
Senior — может работать со сложным ТЗ, подсказывает, как сделать оптимальнее и проще, сам общается с внутренними заказчиками и декомпозирует задачи, ревьюит и направляет коллег.
Конечно, к этому описанию стоит относиться очень условно. Бывает, например, что техническая экспертиза очень велика, и она перекрывает слабые стороны, которые у всех нас есть. В любом случае, мы с каждым сотрудником обсуждаем его уровень и готовы объяснить, почему оцениваем его соответствующим образом, и где нужно прибавить, чтобы перейти на уровень выше.
Кто чаще возглавляет команды — продуктовый специалист или технический?
Павел: Прямыми руководителями команд разработки у нас выступают только технические специалисты. Тем не менее есть руководители продуктов, неявным образом они тоже руководят командами — через планы, например. Но все-таки основной руководитель команды один — технический.
Как часто люди меняют команды?
Павел: Мы активно растем, так что у нас формируются новые команды, куда мы готовы рассматривать людей из текущих команд. Помимо этого мы всегда готовы к ротации людей между командами, если у кого-то будет такое желание.
Подобное случается, но не слишком часто. Последние трансферы были летом 2020 для формирования команды статистических сервисов. Ряд людей из других отделов были выделены под проект по переносу статистики на нового поставщика данных. В итоге временный проект перерос в постоянный, а команда статистики с тех пор увеличилась в два раза.
Что важнее, софт-скиллы или хард-скиллы?
Павел: Сто процентов для нас важнее софты. Технические дыры мы сможем закрыть онбордингом, обучением и опытом коллег. А личностные особенности человека мы изменить не сможем при всем желании.
Даже в случае с поиском специалистов DevOps или архитекторов мы вряд ли примем к себе технически подкованного кандидата, если на интервью не сможем найти с ним общий язык.
Как много собраний у вас проводится? Есть ли особые подходы к ним?
Павел: Все очень зависит от твоей роли в команде. У всех сотрудников есть одна обязательная встреча в неделю — встреча, на которой представители разных направлений от разработки до продаж делятся тем, что было сделано за неделю, событиями, интересными графиками и цифрами. Встреча обычно занимает не более получаса.
В каждой команде разработки есть ежедневные стендапы. В абсолютном большинстве команд — это встреча на минут 10–15, где каждый рассказывает, что делал, что будет делать и какие были проблемы, если были. Проводятся они в начале дня.
Раз в две недели проводится ретро и несколько раз неделю проводятся получасовые встречи по оценке задач из бэклога. На этом для большинства сотрудников регулярные встречи заканчиваются.
Как вы боретесь с выгоранием сотрудников?
Павел: Мы всегда идем навстречу, если сотрудник начинает выгорать: меняем нагрузку, меняем задачи, готовы предлагать длительные отпуска, переводить в другие команды, менять формат работы. Самое сложное — это вовремя обнаружить начало выгорания.
Главное наше «оружие» в этом деле — это регулярные тет-а-теты. Еще рамках performance review мы просим каждого сотрудника заполнить по себе документ с описанием своих успехов и неуспехов, общей оценки собственной деятельности и целях. В подобных ответах тоже часто можно проследить настроение сотрудника.
Но, в целом, командная работа, личный и внимательный подход к каждому сотруднику, периодические корпоративы и тимбилдинги — все это способствует уменьшению риска выгорания.
О технологиях
Какие языки, фреймворки и библиотеки используются на проекте?
Павел: Бэкенд — все новое на Golang (gRPC-Go, GraphQL-Go, gorilla/mux, logrus). Исторически проект писался на Perl (Ontico, Mason) и PHP (ZF1), однако эти части находятся на поддержке без развития.
Фронтенд — большая часть на Vanilla-js, все новые разделы пишутся на Vue, Node.js. Сейчас затягиваем к себе TypeScript.
Что вы можете рассказать об архитектуре проектов?
Павел: Архитектура бэкенда Sports.ru построена на микросервисах (Golang), которые запускаются в кластере Kubernetes в нескольких экземплярах. Нагрузка мониторится на разных уровнях (БД, очереди, CPU и RAM-контейнеров). Сервисы спрятаны за гейтвеем, с которым внешний мир общается по GraphQL API. Микросервисы с гейтвеем и между собой взаимодействуют по gRPC. Асинхронное межсервисное взаимодействие базируется на RabbitMQ.
Есть некоторое количество трафика, которое обрабатывается в легаси монолитах (Perl, PHP), которые зачастую используются как прокси в GraphQL для обеспечения обратной совместимости. Но, например, админка пока живет только в монолите.
Со стороны фронта новые страницы, написанные на Vue стеке, работают по стандартной Flux-архитектуре с использованием SSR, с бэкендом общаясь по GraphQL API. Остальная часть сайта по большей части работает на шаблонах, в которые напрямую передаются данные от бэкенда по паттерну MVC.
Какая у вас принята политика код-ревью?
Павел: Код-ревью — это обязательная ступень в воркфлоу любой задачи. Разработчик создает мердж-реквест в GitLab, ставит как минимум двух ревьюеров и переводит задачу в соответствующий статус в Jira. В Slack приходит сообщение о необходимости ревью с указанием конкретных людей. После того, как по ревью все вопросы закрыты, мердж-реквест принимается, и задача двигается на следующую ступень, которая уже может отличаться в зависимости от команды.
У нас нет ограничений по тому, кто допускается до код-ревью, как и нет тех, кто должен все ревью пропускать через себя. Важно не отдавать ревью только одним и тем же людям, чтобы не было «узких горлышек» и чтобы больше людей знакомились с новым кодом.
Доски в Jira всем открыты, сообщение в Slack падает в общий чат, список мердж-реквестов по репозиторию всем виден. Так что если кому-то особо интересно то или иное ревью, то он сам может добавиться и оставить комментарии.
Как тестируется код?
Павел: В бэкенде все новые микросервисы в обязательном порядке покрыты unit-тестами, в некоторых местах присутствуют и интеграционные тоже.
Во фронте главным образом пишутся unit-тесты. А также используются инструменты для слежения за визуальной консистентностью (storybook). Старый код покрыт частично, в основном с защитой от нелепых ошибок — например, эндпоинты легаси REST API проверяются на соответствие описанной схеме. Помимо этого интеграционные end-to-end пишутся командой QA на Playwright. Тестировщики также проводят приемочное и регрессионное тестирования.
Как устроен процесс документации и ведения базы знаний на проектах?
Павел: У нас есть очень четкое разграничение в Jira по проектам. У каждой команды свой проект. Даже у команды продактов есть свой отдельный проект, где и зарождаются задачи с полными ТЗ, ссылками на макеты, указанием требований от аналитиков. Далее уже команды разработки в своих проектах создают техническую декомпозицию, связывая свои задачи с продуктовой. Такая схема позволяет всегда найти этот единый источник правды в виде полностью описанной необходимой функциональности.
Также мы ведем документацию в wiki (пока используем движок xwiki). Там описаны все наши процессы разработки, особенности используемых инструментов исервисов, ведется раздел с постмортемами и так далее.
И, конечно, есть README-файлы в репозиториях с описанием сервисов и какими-то их особенностями.
Каков процент легаси-кода на проекте и как часто разработчики занимаются его рефакторингом?
Павел: Точный процент оценить не берусь, но на данный момент он все еще выше, чем хотелось бы. Если брать бэкенд, то значительная часть ключевой функциональности лежит в монолитах, которые мы причисляем к легаси. Эти монолиты мы не развиваем, а переписываем их на новый стек в рамках больших технических проектов. Есть полное понимание от бизнеса в необходимости больших вложений в этот процесс, поэтому миграция идет не так тяжело.
Стоять на месте продуктово при этом, конечно, мы не можем и часть ресурсов постоянно выделяем на новые фичи, которые пишутся сразу на новом стеке. Это касается только одной из бэкенд-команд. Две другие были созданы относительно недавно и работают исключительно с новыми сервисами и только на актуальном стеке.
Во фронтенде также происходит актуализация стека, но мы объединяем это с продуктовым пересмотром разделов / страниц / виджетов. Например, одна из самых посещаемых страниц на сайте, «онлайн-матча», не так давно была полностью переписана на Vue с обновлением дизайна и пересмотром ряда функциональностей. Аналогичных изменений у нас уже запланировано немало.
Рефакторингу мы, конечно, уделяем время и стараемся по возможности соблюдать «правило бойскаута»: оставь место стоянки чище, чем оно было до твоего прихода. Но без фанатизма, конечно :)
Оценивайте своих работодателей на Хабр Карьере, а если захочется узнать о Sports.ru что-то ещё — пишите вопросы в комментах, мы позовем кого-нибудь из ребят отвечать!
→ оценить работодателя
