У нас гайдлайн обычно бодро начинается: цвета, типографика, кнопки, пара примеров. А через полгода в макетах уже новые состояния, в коде — другие названия, и никто не уверен, что считать актуальным. Как вы не даёте таким документам превратиться в архив хороших намерений?
Мне кажется, важнее не описать всё на старте, а договориться, кто и когда обновляет правила. Например, любое изменение компонента сопровождается правкой примеров и короткой записью о том, что поменялось. Но не хочется превращать каждую мелочь в бюрократический процесс и тормозить команду.
Интересно, где у вас живёт гайдлайн: рядом с макетами, в документации к коду или в отдельном сервисе? Кто отвечает за расхождения между ними? И что вы делаете с устаревшими вариантами — удаляете, помечаете как архивные или оставляете для старых проектов? Поделитесь практиками, которые реально прижились, и тем, что не сработало.
Мне кажется, важнее не описать всё на старте, а договориться, кто и когда обновляет правила. Например, любое изменение компонента сопровождается правкой примеров и короткой записью о том, что поменялось. Но не хочется превращать каждую мелочь в бюрократический процесс и тормозить команду.
Интересно, где у вас живёт гайдлайн: рядом с макетами, в документации к коду или в отдельном сервисе? Кто отвечает за расхождения между ними? И что вы делаете с устаревшими вариантами — удаляете, помечаете как архивные или оставляете для старых проектов? Поделитесь практиками, которые реально прижились, и тем, что не сработало.
Комментарии 8
Обсуждение темы — по порядку