Тезис про публикацию не в сторону микрофронтов, а больше про версионирование. Хотел тут упомянуть, что монорепозиторий позволяет напрямую связывать пакеты локально строчкой в package.json, при этом иметь высокий уровень изолировать кода друг от друга
Монорепозиторий действительно не исключает микрофронтенды - это решения разных уровней.
В нашем случае благодаря монорепозиторию и структуре пакетов/кода нам нет необходимости идти в микрофронтенды, которые сами по себе являются довольно дорогим решением.
Микрофронтенды хорошо решают проблемы высокой связанности, конфликтов и снижения межкомандного взаимодействия за счёт runtime-изоляции и независимых сборок, но часто в них идут преждевременно. Я решил показать в статье альтернативный подход: значительную часть задач можно решить со стороны структуры - через чёткие границы пакетов, изоляцию зависимостей и настройку пайплайнов, не усложняя продакшен оркестрацией бандлов.
И мы понимаем ограничения такого подхода. Например, наши команды не получают полностью независимые релизы и хуже масштабируются, имеют общие зависимости. Однако они так же работают в рамках своих пакетов, сохраняя изоляцию на уровне кода, переиспользование общих модулей и более простую инфраструктуру. Некоторые фичи микрофронтов у нас закрывают автоматические проверки:
dependency check и dedupe следят за консистентностью зависимостей
сборка приложений, запуск и проверка runtime гарантируют, что баг в одном пакете не поломает все приложение
много интеграционных тестов с честным рендерингом UI ловят локальные runtime регрессии и ошибки на границах модулей
Кстати, у нас достаточно интересная инфраструктура автотестов. Если будет интересно, можем подробно разобрать её в отдельной статье.
Согласен, что «люди-оркестры» выгорают. Мы как раз не ищем таких.
Речь не о том, чтобы один аналитик делал за всех, а о том, чтобы в команде были мыслящие партнёры, которые видят продукт целиком, задают критические вопросы и формулируют гипотезы.
Мы ждём от продуктовых аналитиков опыта в работе с продуктом: эксперименты, метрики, влияние на решения, на бизнес. Это и есть суть продуктовой аналитики. Нет, необязательно быть прекрасным кодером или иметь финансовый опыт, но для получения результатов нужно писать код на SQL, Python и проводить анализ. То, что я описал – это не про человека оркестра, а стандартные требования к продуктовому аналитику.
Хорошая мысль про тандем. Когда роли дополняют друг друга – это прекрасно работает. Я обычно начинаю с другого конца — сначала разбираюсь, зачем вообще тандем нужен и правда ли он решит проблемы команды
на собеседованиях мы не гонимся за количеством. эффективное выполнение задач, которые не нужно решать, сводит ценность приложенных усилий к нулю.
в первую очередь смотрим на мышление: как человек рассуждает, на что обращает внимание, как формулирует гипотезы и проверяет логику решения. навык мышления можно и проще проверять без ИИ, поэтому не вижу никакого двойного стандарта.
навыки владения инструментами (SQL, Python, ИИ) и умение решать типовые задачи тоже важны, но вторичны. мы смотрим на них на первом этапе, а дальше даём два продуктовых кейса без «правильного ответа» – чтобы увидеть, как человек мыслит, структурирует и делает выводы.
если кратко: навык работы с ИИ нужен, без него никуда, но это второй приоритет. Умение мыслить и анализировать самостоятельно – первый. без первого не будет второго.
у нас четыре основных этапа отбора: два технических интервью, встреча с HR и интервью по ценностям. если всё проходит успешно, мы можем попросить контакты коллег для рекомендаций.
алгоритмические задачи (leetcode) у нас есть, но фокус на том как кандидат мыслит, а не на оптимальном решении.
задачки на листочке решать не нужно, но если нужен листочек – можно им пользоваться. Предлагаем простой онлайн редактор для кода.
у нас все аналитики (маркетинговые, продуктовые) пишут код (Python, SQL) для расчетов в исследованиях, экспериментах и так далее. это код не для прода (аналитики – не инженеры), а для вычислений
согласен, что перечисленные практики важны. мы к ним тоже постепенно приходим, но видим в них не отправную точку, а следствие любопытства.
сначала человек начинает задавать вопросы, спорить, что-то инициировать – и мы помогаем этому импульсу найти форму (в виде аналитической модели, исследования, обзора, доклада, и так далее).
я в своём ответе как раз говорил о том, что мы делаем до этого шага – чтобы это любопытство и инициатива вообще появились. мы стараемся создать среду, где безопасно предлагать, где инициативу не гасят, где руководитель не приходит с готовыми ответами.
1. а) примерно на 70% б) на 8 — для текущего состояния бизнеса
важный момент: мы как компания не маленькие — можем позволить себе ждать и выбирать нужных кандидатов. но и не настолько большие, чтобы нужно было нанимать постоянно и много.
2. развитие BI и витрин важно, но да, вторично по сравнению с развитием членов команды.
что делаем для этого:
развиваем менеджеров (у нас есть внутренние курсы)
разговариваем и поощряем инициативу (101, сбор ОС)
стараемся приходить с вопросами и проблемами, а не с готовыми решениями
уменьшаем рутину и операционные задачи
если видим, что человек начал приходить с идеями, ответами, инициативами, предложениями — значит это то, что нам нужно)
у нас получается нанимать людей, которым хорошо в компании и нравится решать задачи продукта. из-за этого и бизнес видит пользу и растёт. статья в том числе про это)
ну вот внизу посоветовали какую-то другую модель, мы еще не пробовали, пока не можем ничего сказать, но затестить можно) если нужен только текст, без сложной углубленной логики - почему нет
видели тоже, можно достраивать промпт, что-то в духе "не разбивай текст на строки, если это не обосновано нехваткой места в строке". сотни вариантов, но придется вручную, да)
Привет! Да, конечно пользуемся, но подходим осознанно, потому что переиспользование поднимает ответственность кода и усложняет его поддержку. Всегда используем на уровне core библиотек: api client, тулкит, логгер, аналитика. Стараемся выносить общую бизнес логику в общих частях, вроде чатов или авторизации. На уровне страниц и ui виджетов бизнес логику чаще делим по платформам
мы используем Detox для e2e перед релизами и Detox с кастомным mock сервером для компонентных UI тестов по аналогии, как работает cypress + msw на вебе
я думаю, что тут проблема с перерендером в случаях, когда надо использовать маску на инпуте. можно посмотреть в сторону input-mask-ios , либо на стороне кода постараться минимизировать количество ререндеров (менять value через ref, не использовать стейт для значения)
в голову приходит ток одно: кто-то любит сидеть НА столе, а не за ним
Тезис про публикацию не в сторону микрофронтов, а больше про версионирование. Хотел тут упомянуть, что монорепозиторий позволяет напрямую связывать пакеты локально строчкой в package.json, при этом иметь высокий уровень изолировать кода друг от друга
Ответил, работа замотала, готов к дискуссии))
Монорепозиторий действительно не исключает микрофронтенды - это решения разных уровней.
В нашем случае благодаря монорепозиторию и структуре пакетов/кода нам нет необходимости идти в микрофронтенды, которые сами по себе являются довольно дорогим решением.
Микрофронтенды хорошо решают проблемы высокой связанности, конфликтов и снижения межкомандного взаимодействия за счёт runtime-изоляции и независимых сборок, но часто в них идут преждевременно. Я решил показать в статье альтернативный подход: значительную часть задач можно решить со стороны структуры - через чёткие границы пакетов, изоляцию зависимостей и настройку пайплайнов, не усложняя продакшен оркестрацией бандлов.
И мы понимаем ограничения такого подхода. Например, наши команды не получают полностью независимые релизы и хуже масштабируются, имеют общие зависимости. Однако они так же работают в рамках своих пакетов, сохраняя изоляцию на уровне кода, переиспользование общих модулей и более простую инфраструктуру. Некоторые фичи микрофронтов у нас закрывают автоматические проверки:
dependency check и dedupe следят за консистентностью зависимостей
сборка приложений, запуск и проверка runtime гарантируют, что баг в одном пакете не поломает все приложение
много интеграционных тестов с честным рендерингом UI ловят локальные runtime регрессии и ошибки на границах модулей
Кстати, у нас достаточно интересная инфраструктура автотестов. Если будет интересно, можем подробно разобрать её в отдельной статье.
Они ушли в отпуск.
А вы наблюдательные)
Согласен, что «люди-оркестры» выгорают. Мы как раз не ищем таких.
Речь не о том, чтобы один аналитик делал за всех, а о том, чтобы в команде были мыслящие партнёры, которые видят продукт целиком, задают критические вопросы и формулируют гипотезы.
Мы ждём от продуктовых аналитиков опыта в работе с продуктом: эксперименты, метрики, влияние на решения, на бизнес. Это и есть суть продуктовой аналитики. Нет, необязательно быть прекрасным кодером или иметь финансовый опыт, но для получения результатов нужно писать код на SQL, Python и проводить анализ. То, что я описал – это не про человека оркестра, а стандартные требования к продуктовому аналитику.
Хорошая мысль про тандем. Когда роли дополняют друг друга – это прекрасно работает. Я обычно начинаю с другого конца — сначала разбираюсь, зачем вообще тандем нужен и правда ли он решит проблемы команды
на собеседованиях мы не гонимся за количеством. эффективное выполнение задач, которые не нужно решать, сводит ценность приложенных усилий к нулю.
в первую очередь смотрим на мышление: как человек рассуждает, на что обращает внимание, как формулирует гипотезы и проверяет логику решения. навык мышления можно и проще проверять без ИИ, поэтому не вижу никакого двойного стандарта.
навыки владения инструментами (SQL, Python, ИИ) и умение решать типовые задачи тоже важны, но вторичны. мы смотрим на них на первом этапе, а дальше даём два продуктовых кейса без «правильного ответа» – чтобы увидеть, как человек мыслит, структурирует и делает выводы.
если кратко: навык работы с ИИ нужен, без него никуда, но это второй приоритет. Умение мыслить и анализировать самостоятельно – первый. без первого не будет второго.
у нас четыре основных этапа отбора: два технических интервью, встреча с HR и интервью по ценностям. если всё проходит успешно, мы можем попросить контакты коллег для рекомендаций.
алгоритмические задачи (leetcode) у нас есть, но фокус на том как кандидат мыслит, а не на оптимальном решении.
задачки на листочке решать не нужно, но если нужен листочек – можно им пользоваться. Предлагаем простой онлайн редактор для кода.
ИИ просим не пользоваться на собеседованиях.
у нас все аналитики (маркетинговые, продуктовые) пишут код (Python, SQL) для расчетов в исследованиях, экспериментах и так далее. это код не для прода (аналитики – не инженеры), а для вычислений
согласен, что перечисленные практики важны.
мы к ним тоже постепенно приходим, но видим в них не отправную точку, а следствие любопытства.
сначала человек начинает задавать вопросы, спорить, что-то инициировать – и мы помогаем этому импульсу найти форму (в виде аналитической модели, исследования, обзора, доклада, и так далее).
я в своём ответе как раз говорил о том, что мы делаем до этого шага – чтобы это любопытство и инициатива вообще появились. мы стараемся создать среду, где безопасно предлагать, где инициативу не гасят, где руководитель не приходит с готовыми ответами.
привет, спасибо за комментарий! отвечаю:
1.
а) примерно на 70%
б) на 8 — для текущего состояния бизнеса
важный момент: мы как компания не маленькие — можем позволить себе ждать и выбирать нужных кандидатов. но и не настолько большие, чтобы нужно было нанимать постоянно и много.
2. развитие BI и витрин важно, но да, вторично по сравнению с развитием членов команды.
что делаем для этого:
развиваем менеджеров (у нас есть внутренние курсы)
разговариваем и поощряем инициативу (101, сбор ОС)
стараемся приходить с вопросами и проблемами, а не с готовыми решениями
уменьшаем рутину и операционные задачи
если видим, что человек начал приходить с идеями, ответами, инициативами, предложениями — значит это то, что нам нужно)
почему?
у нас получается нанимать людей, которым хорошо в компании и нравится решать задачи продукта. из-за этого и бизнес видит пользу и растёт. статья в том числе про это)
окак, выглядит так, как будто упор на английский язык, нет? с русским так же хорошо работает?
ну вот внизу посоветовали какую-то другую модель, мы еще не пробовали, пока не можем ничего сказать, но затестить можно) если нужен только текст, без сложной углубленной логики - почему нет
просто покаламбурили немного, с кем не бывает... 😅
видели тоже, можно достраивать промпт, что-то в духе "не разбивай текст на строки, если это не обосновано нехваткой места в строке". сотни вариантов, но придется вручную, да)
Привет! Да, конечно пользуемся, но подходим осознанно, потому что переиспользование поднимает ответственность кода и усложняет его поддержку. Всегда используем на уровне core библиотек: api client, тулкит, логгер, аналитика. Стараемся выносить общую бизнес логику в общих частях, вроде чатов или авторизации. На уровне страниц и ui виджетов бизнес логику чаще делим по платформам
мы используем Detox для e2e перед релизами и Detox с кастомным mock сервером для компонентных UI тестов по аналогии, как работает cypress + msw на вебе
привет, прости, немножко задержался с ответом
я думаю, что тут проблема с перерендером в случаях, когда надо использовать маску на инпуте. можно посмотреть в сторону input-mask-ios , либо на стороне кода постараться минимизировать количество ререндеров (менять value через ref, не использовать стейт для значения)