#habr

История об одном рефакторинге:
+ сначала копили джентльменский набор: лишние запросы и библиотеки, спагетти из кода и обещаний, пелена гигабайт в Docker-билде и отсутствие времени даже на размышления;
+ потом рефакторили;
+ теперь стараемся не допустить повторения проблем.

Идея о том, чтобы про всё это рассказать – подсветить частный опыт, который, возможно, натолкнёт вас на какие-нибудь полезные идеи. Не каузация, не агитация, а история одного рефакторинга.

Читать статью

#habr

У нас в ИТ-команде Сравни есть принцип: в любой непонятной ситуации вместо того, чтобы раз за разом решать похожие проблемы, лучше сделать инструмент, который поможет системно решать целый класс таких задач. Шаблонизация, автоматизация занимают важное место у нас в бэклогах. Поэтому эксперименты с Copilot от GitHub и OpenAI, наверное, были для нас неизбежны.

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

Читать статью

#habr

Profile Service — внутренний продукт Сравни, который отвечает за быстрое получение и запись личных данных пользователей для экосистемы Сравни. Ребята из Profile Service взаимодействуют с 20+ продуктовыми командами, которые дают нагрузку на сервис порядка 200-300 RPS; порядок обрабатываемых записей в БД – десятки миллионов.

В какой-то момент в команде Profile Service мы решили внедрить Kafka – де-факто стандарт транспорта, работающий в миллионах проектов. Что может пойти не так? Оказалось – вообще всё что угодно.

В новой статьи на Хабре рассказываем, с какими неочевидными проблемами столкнулись при переходе на Kafka, как чинили баги в NestJS Microservices и какие выводы сделали (спойлер: Kafka – не всегда хорошее решение).

Читать статью

#habr

Технически возможность сравнивать разные предложения завязана на внешние интеграции с нашими партнёрами – страховыми компаниями, банками и так далее.

Сложность тут в том, что каждый партнёр в ответах на наши запросы к их API может присылать десятки разных типов ошибок. Все эти ошибки нужно смотреть и анализировать – это довольно много материала для анализа. Ещё – собственные форматы представления ошибок у разных партнёров, тексты ошибок не всегда прямо говорят о проблемах, перипетии аналитики в Kibana.

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

Сейчас – мы группируем ошибки в PowerBI, регулярно выгружаем статистику по ошибками и отдаём партнёрам, смотрим на динамику изменения числа ошибок, анализируем причины падений, проверяем статистику появление новых ошибок. Видим динамику исправления ошибок, если мы или партнёры работали над соответствующими улучшениями. Находим ошибки непосредственно в интеграциях.

За счёт чего этого стало возможно – читайте в нашей новой статье на Хабре.

Читать статью

#habr

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

Продуктов становилось всё больше, интерфейсы всё сложнее, и иногда, при переходе из раздела в раздел на sravni.ru могло возникнуть впечатление, что это вообще разные сайты. У похожих продуктов были разные паттерны для, казалось бы, одинаковых сценариев. Везде были разные анкеты, разный клиентский путь и визуальное оформление.

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

Процесс создания и внедрения дизайн-системы оказался непростым, не обошлось без разных затыков. Подробности – в нашей новой статье на Хабре.

Читать статью

#habr

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

В новой статье на Хабре рассказываем, как в Messenger-компоненте Symfony устроен механизм повторной обработки сообщений при ошибках (или по-простому – механизм ретраев), а также делимся опытом его использования и некоторыми важными нюансами его работы.

Читать статью

#habr

Бывает так: вроде всё сделали хорошо и проверяли, а сайт всё равно пролежал на выходных с 500-ми ошибками.

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

А помогать с тестированием нам будет Kubernetes-инструментарий в общем (Helm) и механизм хуков в частности.

Подробности – в новой статье в блоге Сравни на Хабре.

Читать статью

#habr

На хабре вышла статья Ахмеда Ахмедова, нашего Deputy of CTO, об опыте управления дежурствами в ИТ-команде ✍
 
Статья точно будет полезна менеджерам IT команд, которые также, как и мы, столкнулись с проблемой размытия ответственности в процессах поддержки внутренних пользователей
 
https://habr.com/ru/companies/sravni/articles/789006/

#репортаж
#habr

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

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

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

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

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

Как выглядит встреча сейчас – посмотрите свежий отчётный ролик на YouTube.

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

===

Рассказать подробнее о каких-нибудь нюансах организации встречи лидов или внедрения улучшений по мотивам? Пишите в комментариях!

#habr

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

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

Но первые реальные практические шаги в этом направлении мы сделали в формате
“А что, так можно было?”: пошли выкладывать приложение в RuStore и попутно обнаружили возможности использовать аналогичные механизмы для настройки кросс-обновления.

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

Спойлер: чтобы всё это завелось, понадобится версия Android API level не ниже версии 28. Но давайте по порядку.

Читать статью

#habr

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

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

В нашей новой статье на Хабре поговорим, как подойти к вопросу мониторинга методологически – задействовать инструментарий инцидент-менеджмента. Обсудим, как оценивать критичность сервисов и какие системы могут быть полезны для отслеживания проблем.

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

Читать статью

#habr 
 
Или станешь менеджером, или накопишь много денег и тогда сможешь дауншифтнуться, кататься на серфе у берегов Австралии, выращивать помидоры в деревне. 
 
В поисках ответов на вопрос “А куда дальше развиваться в профессии?” всё ещё много стереотипов и движения по инерции, но кажется, становится получше. Инженеры всё чаще имеют возможность двигаться не обязательно в сторону превращения в лида или руководителя, но быть высоко квалифицированными individual contributors. В грейдах появляется больше вариативности.
 
Интересная сторона вопроса – кейсы про горизонтальное развитие, когда люди меняют одну ИТ-роль на другую. Обязательно ли это должно происходить при достижении уровня senior в ранее выбранной роли? Возможно ли в рамках одной компании или чаще связано со сменой работодателя? 
 
Расспросили об их опыте смены роли коллег из ИТ-команды Сравни:
• Таня – прошла путь от специалиста первой линии поддержки до Delivery-менеджера в DevOps-команде; 
• Максим – прошёл путь от QA-инженера к Delivery-менеджеру и затем к Product Owner; 
• Света – из QA-инженера стала Frontend-разработчиком. 
 
Вот, что они рассказали. 
 
Читать статью

#habr 

“Нам нечего обсуждать, давайте пропустим” – такую реакцию на идею провести очередную ретроспективу мы слышали столько раз, что сбились со счёта. 

В теории всё красиво: собрались на отдельную встречу (чтобы сфокусировано обсудить нужную тему), вспомнили недавнюю работу (пока не забылось), определили области для улучшений (итеративное развитие – наше всё). 

На практике же ретроспективы часто получаются поверхностными и малопродуктивными. Участники отмалчиваются или обсуждают одни и те же боли из раза в раз; скучают или параллельно занимаются другими делами; уходят со встречи с ощущением впустую проведенного времени.

Хорошие новости: можно по-другому. Повысить вовлеченность команды в ретроспективу, помочь увидеть конкретный результат своих усилий по улучшению работы. Уйти от вопросов “Что будем обсуждать на ретро?” и “ У нас все хорошо?” к прозрачной картине того, что происходит с командой, чего удалось достичь и куда двигаться дальше. 

Помогут нам в этом процессные метрики – как это работает на практике, читайте в нашей новой статье в блоге на Хабре. 

Читать статью

#habr

В нашем блоге на Хабре — новая статья.

Перевели любопытный материал про исправление ошибок, связанных с наложением ссылок (в оригинале — aliasing bugs).

Читайте, ставьте плюс (если вы пользователь Хабра) и советуйте статью знакомым!

#habr

Выпустили новую статью в блоге на Хабре: наши продуктовые аналитики подробно рассказали о том, как в компании удалось улучшить процессы A/B-тестирования📈

Читайте и делитесь ссылкой!

#habr

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

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

https://habr.com/ru/companies/sravni/articles/829708/

Читайте и делитесь ссылкой!

#habr

«Что там с базами, не пора ли добавлять ресурсов?» — казалось бы, звучит как дежурная реплика менеджера, и классический ответ на неё: «всё ок, до конца недели должно хватить!».

На деле этот вопрос может быть сигналом о целом ворохе проблем. Однажды мы в Сравни решили ответить на него несколько иначе: вместо «до конца недели должно хватить» — сказали: «давайте мигрируем базы в единый кластер, а тяжёлые файлы перенесём в S3».

О том, что из этого вышло, читайте в новой хабр-статье.

Ставьте «плюс», делитесь ссылкой!

#habr

Как не потеряться в данных для аналитики?🤔

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

Но что, если данных в компании много, они отличаются сложной структурой и поступают из разных источников?

Упростить жизнь в такой ситуации призван Data Catalog, и в Сравни мы выбрали популярный вариант — DataHub. Рассказали на Хабре, как меняется работа с данными для аналитики, когда в твоей жизни появляется визуализация потоков данных.

Читайте, ставьте «плюс», делитесь ссылкой!

#habr

Новая статья в нашем блоге на Хабре: перевели полную историю создания Git📖

Советуем всем, кому интересно узнать, как появился один из самых популярных ИТ-инструментов в истории (и второе знаменитое творение Линуса Торвальдса после Linux).

А также всем, кто ищет увлекательный лонгрид на выходные.

Читайте, «плюсуйте» и делитесь ссылкой!

#habr

Автоматизация — краеугольный камень современной аналитики, и речь здесь не только о том, чтобы оптимально настроить масштабные базовые процессы вроде CI/CD.

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

Одним из наших локальных кейсов автоматизации поделились в новой хабр-статье. Рассказали, как наладили регулярный процесс сверки данных из десятков таблиц силами одного специалиста, с помощью уже имеющихся в компании инструментов — low code-платформы и мессенджера.

Читайте, «плюсуйте», делитесь ссылкой!📣