tgoop.com/rdclr_dev/121
Last Update:
Привет, меня зовут Юля, я frontend-разработчик.
Надеюсь, мои знания и мысли пригодятся кому-то и сейчас, даже в столь сложной ситуации.
🦚 На этой неделе мы с вами поговорим о дизайн-системах для фронтенда, обсудим Component Driven Development и заглянем в Storybook.
Зачем это все?
Современные приложения стали сложнее. Они растут, развиваются и масштабируются, а значит, их нужно поддерживать и расширять функционал. Чем больше приложение, тем проблематичнее это делать.
🕵🏻 Перейду сразу к примеру. (Все имена и персонажи выдуманы, любое сходство считать совпадением)
Представим, что разработчик Серёжа пишет приложение с нуля. Все кажется понятным и простым. Но со временем кодовая база разрастается, заказчик вносит правки, на которые Серёжа не рассчитывал, дизайнер переделал пару макетов, а дедлайн все ближе. Что происходит? «Быстрые» правки и костыли превращаются в снежный ком, который растет вместе с проектом. Проблема? Проблема.
🧑🏻🌾 Второй пример. Разработчик Ваня попал в проект, который писал Серёжа. Ваня долго вникает в исходники, пытается что-то изменить в подходе, но это трудно: система негибкая и зависимая. В результате Ваня вынужден подстраиваться под проект, чтобы ничего не сломалось. Работа идет медленнее, трудо- и времязатраты увеличиваются, количество багов растет. Проблема? Проблема.
Думаю, оба примера знакомы многим. Что делать?
🍅 1. Если заказчик дает добро, финансы и время, можно переписать проект. Но это очень редкий случай.
🍒 2. Можно нанять больше разработчиков, чтобы быстрее выполнить задачи. Но это дорого и неэффективно в долгосрочной перспективе.
🥝 3. Можно начать внедрять компонентный подход (CDD) и собирать дизайн-систему для UI — медленно, но верно.
🚀 Самый лучший вариант — использовать CDD с самого начала и стартануть проект с дизайн-системы.
Дальше расскажу, что дает Component Driven Development и как его использовать. Не переключайтесь.
BY RDCLR.DEV
Share with your friend now:
tgoop.com/rdclr_dev/121