Комментарии 2
Хотелось бы более подробно узнать как собиралась аналитика по тем же самым компонентам?
К вот этому вот контенту "Отчет об использовании дизайн-системы; В данном случае отчет о функции канбан-доски перечисляет, сколько компонентов из общей библиотеки используются (12) и каково их процентное соотношение в шаблонах (38%), список этих компонентов и их относительная сложность"
Ох, ответ на этот вопрос стоит отдельного поста (или даже нескольких) от людей, которые эту систему сбора и визуализации аналитики строили, и не все из них до сих пор работают в Райке, а я там скорее мимо проходил, поэтому в самых общих чертах опишу, как всё работает.
Начну с самого простого, сложности компонента: это просто выдуманное число наподобие оценки задачи в story points для условной кросс-функциональной команды. Мы примерно, опираясь на опыт нашей платформенной команды, оцениваем, что сделать гибкий и доступный с клавиатуры компонент Select стоит 80 попугаев, а переиспользуемую директиву для закрытия попапов по Escape всего 16. Таким образом, команда, подключившая себе наш готовый компонент, сэкономила эти 16 или 80 попугаев (если возможности компонента не используются на 100%, то меньше).
Про процентное соотношение и список используемых компонентов: мы берем все упоминания наших компонентов в HTML-шаблонах (для Angular, во всяком случае, для React-стека пока эта фича не реализована) и делим на общее количество элементов верстки. Эта метрика не является целевой, и мы не ожидаем, что она где-то будет существенно превышать 50%, верстка по месту — это нормально.
Теперь про то, что есть "фича" вроде той же канбан-доски с точки зрения кода. Райк состоит из большого числа пакетов в формате npm или же pub (пакетного менеджера Dart), и фичи продукта обычно представляют из себя один или несколько пакетов с кодом UI-компонентов и бизнес-логики, которые называются как-нибудь в духе wrike_featurename_app, wrike_featurename_components, etc. Это позволяет верхнеуровнево понять, из каких пакетов / реп та или иная фича состоит. Мы, однако, пошли намного дальше: каждый файл с кодом (или папка целиком) размечается специальной аннотацией, в которой конкретно указано, к какой фиче код относится, без этой аннотации код в мастер не попадает. Попутно это позволяет не держать в уме или каких-то отдельных табличках, кому какой код принадлежит и кто отвечает за разбор инцидентов, информация о владельцах прописана прямо в самой фиче.
Как сделать большой продукт доступным