Мы добавляем вручную в наши *.less файлы. Но я видел примеры, где это можно делать прямо из фигмы. То есть дизайнеры могут добавить/изменить токен в фигме, а изменения отправятся в репозиторий.
Ну ограничивать часто можно и нужно. И это делается с помощью хорошо спроектированного дизайна/интерфейса или публичного апи, чтобы ты не мог засунуть пальцы в розетку) Такой дизайн будет вести тебя и с ним будет сложнее наговнокодить
Я решил завести этот блог, чтобы найти людей со схожими интересами и делится всем тем, что я переживу и чему научусь на своем пути.
А что хотите получить от подобного знакомства?
Я обычный студент, которого сегодня выгнали со стажировки на направлении фронтенд.
Высока вероятность, что за подобные статьи на хабре заминусуют и мотивация упадёт ещё ниже. Другое дело если напишите как так, почему пропала мотивация, что за универ, и почему всётаки выгнали со стажировки.
Как указано в статье, OpenAPI схема позволяет генерировать клиентский код. Это может быть полезно, когда сервис есть, а библиотеки у него нет. Я так например генерировал клиента для Яндекс Музыки. Описал их Open API схему и сгенерировал JS библиотеку. https://github.com/acherkashin/yandex-music-open-api/blob/main/src/yandex-music.yaml
Ну и можно генерировать аналогично библиотеку, чтобы ходить на свой бэк. Генерируешь схему для методов бэка, а из схемы клиентский код на любом языке.
Я думаю этот формат в основном подходит для юнит тестов, и книга, где он рекомендуется тоже именно о юнит тестах. Когда мы называем тест просто "TestLogin" не совсем понятно, что именно мы тестируем, при каких условиях и какой результат ожидаем. Чтобы всё это понять, мне придётся читать тест целиком. Если же я называю тест "TestLogin_InvalidPassword_ThrowsException", все достаточно понятно, я тестирую вход в систему и при это я передаю неправильный пароль, и как результат должен получить ошибку.
Иногда, к сожалению, коллег нужно постоянно пинать и код ревью затягивается очень сильно. Если разбивать на маленькие ПРы, которые зависят друг от друга, работать становится невозможно, потому что, увы, быстрее от этого ПРы не становятся,. Поэтому иногда проще зафигачить один большой ПР)
Мы добавляем вручную в наши *.less файлы. Но я видел примеры, где это можно делать прямо из фигмы. То есть дизайнеры могут добавить/изменить токен в фигме, а изменения отправятся в репозиторий.
Вот тут описываются такие подходы:
Дизайн-система на токенах в Figma, коде и проде – Константин Подрубный, Wrike
Design token automation from Figma to Storybook
А там есть какой-то способ валидировать используются ли дизайн токены или значения захардкожены?
Прям ужасного качества?)
БКС Банк
Это внутрення разработка или её можно пощупать?
Ну ограничивать часто можно и нужно. И это делается с помощью хорошо спроектированного дизайна/интерфейса или публичного апи, чтобы ты не мог засунуть пальцы в розетку) Такой дизайн будет вести тебя и с ним будет сложнее наговнокодить
Большое спасибо за статью, как раз то, что искал
Я сейчас работаю в такой(
Один раз потратит три часа, в следующий раз сделает за пол часа. Зато есть что читать и потратит всего 3 часа вместо нескольких дней.
А как вы работаете? К вам приходят клиенты и просят оптимизировать их процессы?
Круто, спасибо!
У Вани должность не тимлид а джобсекьюрити)
Да, но это слишком абстрактно. Возможно есть процессы из собственного опыта
Спасибо за статью!
Наверно не хватило немного контекста и конкретики. Кто вы, почему занимаетесь автоматизацией процессов.
Есть какой-то самый удачный пример подобной автоматизации?
А что хотите получить от подобного знакомства?
Высока вероятность, что за подобные статьи на хабре заминусуют и мотивация упадёт ещё ниже. Другое дело если напишите как так, почему пропала мотивация, что за универ, и почему всётаки выгнали со стажировки.
Как указано в статье, OpenAPI схема позволяет генерировать клиентский код. Это может быть полезно, когда сервис есть, а библиотеки у него нет. Я так например генерировал клиента для Яндекс Музыки. Описал их Open API схему и сгенерировал JS библиотеку. https://github.com/acherkashin/yandex-music-open-api/blob/main/src/yandex-music.yaml
Ну и можно генерировать аналогично библиотеку, чтобы ходить на свой бэк. Генерируешь схему для методов бэка, а из схемы клиентский код на любом языке.
Потому что тогда можно указать одновременно все 4 параметра, а нам нужно либо
responsive, либоwidthиheightА можете подробнее описать, чем в этом плане отличается Grerrit от Gitlab'а, например.
Я думаю этот формат в основном подходит для юнит тестов, и книга, где он рекомендуется тоже именно о юнит тестах. Когда мы называем тест просто "TestLogin" не совсем понятно, что именно мы тестируем, при каких условиях и какой результат ожидаем. Чтобы всё это понять, мне придётся читать тест целиком. Если же я называю тест "TestLogin_InvalidPassword_ThrowsException", все достаточно понятно, я тестирую вход в систему и при это я передаю неправильный пароль, и как результат должен получить ошибку.
Иногда, к сожалению, коллег нужно постоянно пинать и код ревью затягивается очень сильно. Если разбивать на маленькие ПРы, которые зависят друг от друга, работать становится невозможно, потому что, увы, быстрее от этого ПРы не становятся,. Поэтому иногда проще зафигачить один большой ПР)