Может ли в 2024 году фронтенд-разработчик не тратить время сперва на изучение макета, а затем на его реализацию в коде, в условиях быстро меняющихся требований бизнес-задач? Да, если использовать готовую дизайн-систему. 

При её отсутствии разработчики либо занимаются копипастом подходящих компонентов из других проектов, либо пользуются шарингом этих компонентов в каком-либо виде (вероятно, даже со сторибуком) — но такой подход имеет свои минусы.

Ранее мы рассказали об общем процессе создания и внедрения нашей дизайн-системы. Сегодня углубимся в технические подробности — поэтапно рассмотрим, что в ходе разработки происходило под капотом. 

Представьте ситуацию. Приходит Product Owner и говорит: «Давайте сделаем новый дизайн страницы сайта». Аналитик берётся за задачу — проводит A/B-тест. Такая же задача случается в соседней команде, в сопоставимом по сложности продукте, — но если в первом случае тест занимал пару часов, то во втором ждать приходится несколько дней. Чем больше команд и аналитиков, тем выше риск разрозненности. 

Унификация процессов помогает минимизировать этот риск, только как к ней лучше подступиться? Подготовить чеклисты, шаблоны, документацию, скрипты..? В нашем случае понадобилось всё это, плюс самодельный инструмент, который автоматизирует статистический анализ результатов A/B-тестов

Под катом пошагово описываем, как мы унифицировали процессы в нашем A/B-тестировании, и что получили на выходе.

Почему появляются баги? Существует много причин, но если мы взглянем на конкретные примеры, то сможем увидеть закономерности — и спроектировать наши системы так, чтобы избежать целых классов ошибок. 

Под катом автор блога Considerations on Codecrafting рассматривает ошибки, связанные с наложением ссылок, предлагает методы их предотвращения и призывает внедрить эти методы на уровне проектирования новых языков.

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

Звучит отлично – в теории.

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

Когда-то так было и у нас. Сейчас – все 30 участников высказываются по очереди, формируют рабочие группы по внедрению улучшений, разносят итоги встреч по своим командам.

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

Как развивался формат общих встреч лидов в Сравни – читайте в этой статье. 

Привет, Хабр! Меня зовут Ахмед, я Deputy CTO в Сравни. 

Сегодня расскажу вам об опыте управления дежурствами в ИТ-команде.

Представьте: вы нашли баг на проде; хотите рассказать о находке коллегам, которые отвечают за эту функциональность. Идёте в рабочий мессенджер, пишете в канал или групповой чат соответствующей команды.

Привет, Хабр. На связи Денис Былинин, системный архитектор из финансового маркетплейса Сравни. Сегодня хочу поделиться подробностями запуска курса по практической разработке для студентов мехмата Новосибирского Государственного Университета, где я выступал в роли составителя программы и основного лектора. 

Курс охватывает широкий спектр тем от продуктового мышления и софт-скиллов до сравнения типов архитектур и DevOps-инструментария и призван познакомить студентов с принципами разработки на реальных (или приближенных к реальности) кейсах. Записи лекций лежат здесь в открытом доступе.