Когда система окупает себя — Примеры
Пример 1 — Подсчёт дублирования до вложения
Руководитель продукта спрашивает, нужна ли приложению дизайн-система, и даёт на ответ неделю — начните с того, что уже есть: пять повторяющихся паттернов и число ручных сборок каждого. Так вы получите подсчёт, по которому видно, какие паттерны стоит систематизировать.
# количества условные, из одного продукта
Паттерн Реализаций Расхождений
Кнопка 11 4
Модальное 7 5
Поле формы 9 6
Подсказка 2 2
Пустое состояние 3 3
Решение
Паттерн Реализаций Вариантов Вердикт
Кнопка 11 4 в систему
Модальное 7 5 в систему
Поле формы 9 6 в систему
Подсказка 2 2 оставить
Пустое состояние 3 3 оставить
Одиннадцать самодельных кнопок с четырьмя поведениями — задача размером с систему, а модальное окно и поле формы идут вплотную следом. У подсказки и пустого состояния по одной реализации, поэтому общий компонент обошёлся бы в управлении дороже, чем экономит. Ошибка — смотреть только на колонку количества и считать кандидатом каждую строку.
Пример 2 — Взвешивание количества по частоте изменений
Те же пять паттернов, но меняются не все. Добавьте частоту изменений и расставьте кандидатов по приоритету. В итоге назовите два паттерна, которые строить первыми.
# количества условные
Паттерн Реализаций Изменений в год
Кнопка 11 4
Поле формы 9 4
Модальное 7 1
Пустое состояние 3 1
Подсказка 2 0
Решение
Паттерн Количество x изменения Приоритет
Кнопка 11 x 4 = 44 строить первым
Поле формы 9 x 4 = 36 строить первым
Модальное 7 x 1 = 7 позже
Пустое состояние 3 x 1 = 3 позже
Подсказка 2 x 0 = 0 никогда
Если умножить количество на частоту изменений, наверх выходят кнопка и поле формы: каждое изменение сейчас приходится вносить в одиннадцати или девяти местах. Модальное окно по одному только количеству выглядит загруженным, однако двигается редко и вполне может подождать. Паттерн, который никогда не меняется, дублировать дёшево — поэтому голое количество само по себе расставляет работу неправильно.