Компонент (программирование)
Компонентный подход программирования широко поддерживается фреймворками (программными каркасами).
См. также
Примечания
Полезное
Смотреть что такое «Компонент (программирование)» в других словарях:
Компонент — Компонента составная часть чего либо целого. В разных отраслях науки и техники может иметь дополнительное, более специфическое значение. В математике Компонента связности Компонента связности графа Компонента вектора или тензора, см.… … Википедия
Компонентно-ориентированное программирование — Парадигмы программирования Агентно ориентированная Компонентно ориентированная Конкатенативная Декларативная (контрастирует с Императивной) Ограничениями Функциональная Потоком данных Таблично ориентированная (электронные таблицы) Реактивная … Википедия
Объектно-ориентированное программирование — Эта статья во многом или полностью опирается на неавторитетные источники. Информация из таких источников не соответствует требованию проверяемости представленной информации, и такие ссылки не показывают значимость темы статьи. Статью можно… … Википедия
Экстремальное программирование — Разработка программного обеспечения Процесс разработки ПО Шаги процесса Анализ • Проектирование • Программирование • Докумен … Википедия
Отражение (программирование) — У этого термина существуют и другие значения, см. Отражение. Для улучшения этой статьи желательно?: Перевести текст с иностранного языка на русский. Н … Википедия
Декларативное программирование — Парадигмы программирования Агентно ориентированная Компонентно ориентированная Конкатенативная Декларативная (контрастирует с Императивной) Ограничениями Функциональная Потоком данных Таблично ориентированная (электронные таблицы) Реактивная … Википедия
Внутрисхемное программирование — (англ. In System Programming, сокр. ISP) технология программирования электронных компонентов (ПЛИС, микроконтроллеры и т. п.), позволяющая программировать компонент, уже установленный в устройство. До появления этой… … Википедия
Метод (программирование) — У этого термина существуют и другие значения, см. Метод. Метод в объектно ориентированном программировании это функция или процедура, принадлежащая какому то классу или объекту. Как и процедура в процедурном программировании, метод состоит… … Википедия
КОМПОНЕНТНО-ОРИЕНТИРОВАННОЕ ПРОГРАММИРОВАНИЕ (КОП) — Парадигма программирования, ключевой фигурой которой является компонент (англ. component oriented programming, COP) Словарь бизнес терминов. Академик.ру. 2001 … Словарь бизнес-терминов
Листинг (программирование) — Исходный код, написанный на JavaScript Исходный код (также исходный текст) текст компьютерной программы на каком либо языке программирования. В обобщённом смысле любые входные данные для транслятора. Исходный код либо транслируется в… … Википедия
Идеология компонентно-ориентированного программирования
Недостатки ООП и трудности, возникающие при моделировании сложных систем
Недостаточный контроль за безопасностью. Опасность утечек памяти. Если в языке программирования нет автоматической сборки мусора, то программист может забыть освободить память, выделенную под объект, или освободить память несколько раз.
Взаимозависимость объектов и проблема хрупкого базового класса. В изменчивых средах или в средах с непредсказуемым поведением становится сложно обеспечить надлежащее функционирование системы с помощью ограниченного набора специализированных классов. Ради небольшого изменения функциональности подчас приходится перестраивать архитектуру всей системы. При изменении базового класса могут возникнуть ошибки в работе унаследованных классов (т.н. проблема хрупкого базового класса).
Зависимость от языка программирования и платформы. Функциональность объекта записывается в виде кода шаблона объекта – класса — на некотором языке программирования. Объекты, написанные на разных языках, могут иметь свою специфику и оказаться в конечном итоге несовместимы между собой.
Высокие требования к квалификации ООП-программиста. В сложных системах, состоящих из большого числа взаимодействующих объектов, от программиста требуются высокая квалификация и большой опыт.
Сложность контроля жизненного цикла объекта. Жизненный цикл объекта начинается с вызова конструктора и заканчивается вызовом деструктора. После уничтожения объекта вся информация о его состоянии теряется. В случае необходимости сохранять состояние объекта, программисту необходимо самому реализовывать часть функциональности CRUD и контролировать жизненный цикл объекта.
Основные особенности КОП и отличие компонента от объекта
Компонент как объект, функционирующий в рамках сложной системы с непредсказуемым поведением и большим временем жизни
Главное отличие компонента от объекта заключается в том, что компонент функционирует в среде как часть единой системы – «фреймворка». Фреймворк предоставляет унифицированный способ доступа к ресурсам среды в рамках компонентной модели. Под средой (или окружением) обычно понимается среда выполнения — вычислительное окружение, необходимое для выполнения программы. В конечном итоге компонент взаимодействует как с операционной системой/виртуальной машиной, так и с пользователем, БД, периферийными устройствами и прочими объектами реального мира, используя возможности фреймворка. В контексте жизненного цикла разработки ПО, под средой также может пониматься среда разработки, среда выполнения и т.п.
Компонент может рассматриваться как объект, к которому предъявлен ряд дополнительных требований для функционирования в сложных средах с элементами неопределенности. Базовый класс компонента должен содержать всю необходимую функциональность, которая позволяет называть компонент компонентом.
Если жизненный цикл объекта в ООП, как правило, известен заранее вплоть до мельчайших деталей еще на этапе разработки архитектуры системы, то компоненты, являющиеся частью сложной системы, могут инициировать взаимодействие друг с другом в различное время «по требованию». При этом они изначально могут ничего не знать друг о друге — на этапе написания компонента программист ограничен возможностями компонентной модели. Поэтому компоненты должны уметь динамически «обрабатывать» события и обмениваться информацией о своих свойствах и умениях с другими компонентами.
Вот некоторые особенности, в той или иной мере присущие компонентно-ориентированному программированию: интроспективность (способность компонентов к самоописанию), модульность и разграничение уровней доступа, автоматическая обработка исключительных ситуаций, автоматическое управление памятью, позднее связывание и динамический контроль типов, обработка событий, персистентность (способность компонентов сохранять и восстанавливать состояние), простота повторного использования.
Компоненты могут представлять сущности моделируемой системы, ресурсы среды (предоставлять доступ к файловой системе, базам данных), управлять рабочим потоком, предназначаться для выполнения определенных задач.
Различные жизненные циклы и среды
С точки зрения аспекта разработки ПО, жизненный цикл компонента обычно начинается после того, как код на некотором языке программирования скомпилирован в виде модуля (сборки) и установлен в среду проектирования.
После этого компонент готов к взаимодействию со средой проектирования и используется разработчиком на этапе проектирования целевой информационной системы.
После развертывания целевой системы компонент взаимодействует с исполняемой средой и обычно с пользователем, для которого, как правило, и предназначена спроектированная система.
Способность компонента к описанию собственных свойств и умений
Компоненты в КОП-мире функционируют не сами по себе, а в рамках системы («фреймворка»). Поэтому им необходимо иметь способ предоставлять информацию о себе, например, с помощью метаданных, и получать информацию от других компонентов системы. Метаданные могут содержать описание возможностей компонента, их доступности в каждой поддерживаемой среде и особенностей работы с ними.
В дополнение к привычным сущностям ООП мира – полям и методам, КОП предлагает новые концептуальные понятия – свойства, события, команды, модули и т.д.
Изменение внутреннего состояния компонента производится с помощью изменения соответствующих свойств.
Для реакции на события внешней среды в КОП используются обработчики событий. Могут потребоваться дополнительные способы контроля поведения компонента, реализованные в виде правил и ограничений.
Полный набор правил, описывающих взаимодействие компонентов друг с другом в рамках фреймворка, образует компонентную модель.
Способность компонента сохранять и восстанавливать свое состояние
При переходе из одной среды в другую между жизненными циклами, компоненты должны иметь возможность где-то хранить свое состояние. Для этого от разработчика компонента может потребоваться реализация определенных интерфейсов или применение паттернов проектирования. Обычно это достигается за счет сериализуемости компонента (Serializable).
Способность к взаимодействию, при этом независимость компонентов друг от друга
Архитектура КОП-системы построена таким образом, что компоненты не зависят друг от друга и являются взаимозаменяемыми. Архитектор может собирать требуемую систему из компонентов как из кубиков детского конструктора. В случае изменения функциональности компонента, от программиста может потребоваться перекомпилировать отдельный компонент, но не все приложение.
При этом компонент не автономен – он находится в тесном взаимодействии со средой. О среде компонент знает ровно столько, сколько ему необходимо для реализации заявленной функциональности.
Миграция компонентов между средами вместо компиляции
В КОП принято говорить об установке компонентов, когда скомпилированные сборки, или пакеты, содержащие компоненты, устанавливаются в среду проектирования. Компоненты готовы к использованию сразу после попадания в среду.
Теоретически в КОП может и вовсе отсутствовать привычный этап компиляции. Функциональность компонента может «виртуально» существовать в базе данных или в файловой системе и загружаться или даже меняться по мере необходимости.
Дизайн вместо программирования
При сборке системы из компонентов становится возможным создавать сложные информационные системы без единой строки кода!
Введение в компонентно-ориентированный подход к программированию
Сам Unity Engine (далее Unity), как и многие другие игровые движки, наиболее приспособлен к компонентно-ориентированному программированию (далее КОП), так как Behavioral Pattern — один из базовых паттернов архитектуры движков, наряду с паттерном «Component» из классификации Decoupling Patterns. Потому именно компонент является базовой единицей для реализации бизнес-логики в Unity. В этой статье я расскажу о том, как применять КОП в Unity.
В целом, КОП можно рассматривать как развитие принципов ООП с устранением проблемного места, известного как хрупкий базовый класс. В свою очередь развитием КОП можно считать Сервис-Ориентированное программирование. Но вернёмся к теме. Стоит сразу отметить, что КОП-КОПом, но никогда нельзя забывать о принципах GRASP, SOLID и других.
Теперь обратим внимание на GRASP. Программирование должно быть на уровне абстракций, а не конкретных реализаций (Low Coupling (Низкая связанность)). И даже, казалось бы, простой геймплей, требует создания UML диаграмм интерфейсов. Зачем? Не излишне ли это, принцип «YAGNI» (You Ain’t Gonna Need It) не даёт покоя. Не излишне, когда обоснованно. Кто придумывает игру? Гейм-дизайнеры, вот эти коварные люди гражданской наружности. И не бывает так, чтобы они что-нибудь не изменили. Потому надо быть готовым к изменениям, но ещё чаще нужно быть готовым к расширению игровой логики. При том, все эти изменения будут внесены не сразу, а тогда, когда уже и сами разработчики забудут, почему сделано так, а не иначе. Поэтому UML-диаграммы, хотя бы абстракций, всегда нужно делать: это документация к проекту. UML диаграммы я буду разрабатывать в Visual Studio, чтобы потом сгенерировать по ним код C#.
Итак, приступим к разработке игры; например, создадим core gameplay игры жанра Tower Defense. Существуют разные подходы к шагам разработки, я буду использовать сокращённый вариант.
Первый шаг: постановка задачи
Сколько бы многостраничной документации не было создано по игре, нужно всегда уметь выделить основное. Примерное описание игрового процесса, конечно, лучше разделить на use case:
Игрок должен не дать врагам разрушить Дом. Для это он должен расставить башни, которые будут уничтожать врагов, попавших в радиус действия. Одновременно одна башня может атаковать только одного врага. Когда он погибает или выходит из радиуса действия башни, выбирается следующий из доступных. Враги появляются волнами, с каждой волной их количество увеличивается. Враги движутся из точки появления по дороге до Дома. Подойдя к дому начинают его разрушать. Когда дом разрушен — игра окончена.
Второй шаг: анализ задачи
Начнём с проработки главного: башен, крипов и дома. Так, создав сцену с уже расставленными игровыми объектами (башнями и домом), мы должны получить результат: крипы появляются, движутся к дому, погибая по пути от урона башен, а дойдя до дома, наносят ему урон. При смерти крип исчезает со сцены. При разрушении дома или унитожении всех крипов — игра окончена.
Выделим главные игровые сущности, укажем их свойства и поведение:
1) Башня. Свойства: урон, кулдаун между выстрелами, радиус выбора цели, логика выбора цели.
Поведение: выбор цели и атака цели.
Также для разнообразия геймплея будут разные виды башен: по урону, радиусу поражения и логике выбора цели.
2) Крип. Свойства: HP, урон, кулдаун между атаками, скорость перемещения.
Поведение: Перемещение по маршруту до Дома. Атака дома при подходе к нему вплотную. Когда HP = 0, считается убитым.
Разные виды крипов — например, по HP.
3) Дом. Свойства: HP.
Поведение: Когда HP = 0, игрок проиграл.
Третий шаг: декомпозиция
Я считаю, что правильная декомпозиция задач очень важна. Большую часть времени стоит потратить на проработку абстракций и логической связи между ними.
Начнём с обобщения поведения, чтобы выявить какие должны быть компоненты.
1) В игре есть две сущности, обладающие поведением нанесения урона: башня и крип. Выделим это поведение в компонент, вот его интерфейс:
Стойте-стойте, кто-то скажет: “А как же инкапсуляция? Выходит, что кто угодно может изменить кулдаун и урон?” Нет, только геймдизайнер, настраивая интуитивно-понятным образом свойства компонента. Поэтому у всех свойств будет только get, чтобы отображать информацию в UI, а set не понадобится. Кроме того, Unity не сможет отобразить в инспекторе свойства с указанной конструкцией get/set, и понадобится создавать поля, отмеченные [SerializeField]. И это правильно, другие классы из кода не смогут изменить значение свойства.
Вернёмся к компоненту. Кто-то будет вызывать запуск этого поведения и останавливать его, указывать цель, сменять цель. Но кто?
2) Так как логика выбора цели будет разная у разных типов башен, а также не только башня, но и крип будут использовать это поведение, то надо выделить два логических компонента.
Первый будет работать с физикой, как только в коллайдер-триггер вошёл крип, он его добавляет в очередь целей, создавая событие, что мол целей прибавилось. Как только крип покинет зону поражения — убрать эту цель из очереди, создать событие удаления крипа из очереди.
Конечно для дома это поведение избыточно: дом никогда не убежит. Ну да ладно. Назовём этот интерфейс будущего компонента ITrigger. С двумя методами Unity: OnTriggerEnter/OnTriggerExit.
Второй логический компонент будет реагировать на эти события и использовать уже сам IDamageDealer для нанесения урона выбранной цели и прекращения нанесения урона.
Но как тогда сделать так, чтобы тот второй компонент по-разному выбирал цель, в зависимости от типа башни и если это вообще крип? Простой вариант — некий универсальный метод SelectTarget (Тип логики выбора цели (тип башни, крип)), в зависимости от типа логики выбора цели выбрать её. Но универсальность не всегда хороша, особенно если дело касается компонентов. Тут вспоминается Interface Segregation Principle: лучше несколько конкретных, чем один универсальный. Поэтому будут разные компоненты для разного поведения выбора цели, объединённые одним интерфейсом ITargetSelector.
KeepSelector: выбирает в качестве цели дом.
SimpleCreepSelector: выбирает первую в списке цель.
WeakCreepSelector: выбирает самую слабую цель чтобы добавить её.
Таким образом легко расширить core-gameplay механику выбора цели (механика основная, так как башни только ей различаются). Однако, можно и другой вариант сделать, с наследованием. Будет базовый компонент TargetSelector с дефолтной логикой для башни. А класс KeepSelector и WeakCreepSelector будут переопределять метод добавления в список целей (чтобы проверить дом это или крип) и метод выбора цели.
3) В игре есть две сущности, обладающие следующим поведением: при получении урона уменьшается количество очков жизни, пока не умрёт.
Почему надо IsDead, когда можно просто проверь условие HP
Руководство по разработке, основанной на компонентах
Модульность является одним из ключевых принципов разработки программного обеспечения с 1960-х годов. Применение этого принципа приносит в программирование много полезного. Модульность способствует эффективному использованию принципа разделения ответственностей, что ведёт к улучшению возможностей по созданию, многократному использованию, компоновке кода.
В наше время применение принципа модульности в проектировании ПО приняло новую форму, воплотившуюся в компонентах. Это — разработка, основанная на компонентах (Component Driven Development, CDD). Современные библиотеки и фреймворки для разработки пользовательских интерфейсов, такие как React, Vue и Angular, а также CDD-ориентированные инструменты наподобие Bit, позволяют создавать приложения, опираясь на модульные компоненты. В распоряжении программиста оказываются паттерны и инструменты, необходимые для разработки компонентов в изоляции и построения композиций компонентов.
Компонент — это чётко очерченный независимый фрагмент интерфейса приложения. В качестве примеров компонентов можно привести такие сущности, как кнопки, слайдеры, окна для вывода сообщений чатов. Понимая особенности CDD и умея применять этот подход к разработке, мы можем использовать компоненты в качестве основы приложений. Это, при создании программных проектов, даёт нам всё то полезное, что означает применение принципов модульного программирования.
Если присмотреться к тому, что происходит сейчас в сфере веб-компонентов, можно заметить, что CDD становится стандартизированным подходом к разработке фронтенда.
Материал, перевод которого мы сегодня публикуем, представляет собой руководство по разработке, основанной на компонентах.
CDD в разработке пользовательских интерфейсов
Работа в Bit: создание компонентов, их изоляция, многократное использование и совместная работа над ними
Попросту говоря, разработка, основанная на компонентах, представляет собой проектирование приложений посредством создания слабо связанных друг с другом независимых блоков кода. У каждого из них есть интерфейс, предназначенный для организации взаимодействия с другими частями системы. Множество компонентов, объединённых друг с другом посредством композиции, формируют модульное приложение.
Например, применение CDD при создании React-приложений означает, что сначала создают компоненты, формирующие основу приложения, а потом приступают к сборке из них более крупных частей приложения, таких как целые страницы и крупные блоки функционала.
CDD соотносится с атомарным дизайном (вот полезный материал на эту тему) и с подходом к разработке клиентских частей веб-проектов, известным как «микро-фронтенд».
CDD помогает разбить процесс разработки большого проекта на более мелкие процессы разработки отдельных компонентов. Каждый компонент проектируется независимо от остального приложения и создаётся с учётом возможности взаимодействия с другими частями системы. Проектирование каждого компонента в виде самостоятельной сущности даёт разработчику множество полезных возможностей.
Эдди Османи изложил некоторые основные преимущества применения CDD. Он оформил их в виде набора принципов, названного FIRST.
Инструменты CDD
Если разработка основана на компонентах — это означает, что программисту нужны специализированные инструменты. Такие инструменты направлены на создание компонентов, на их тестирование, на организацию общего доступа к ним и на поддержку совместной работы над ними.
В частности — важно разрабатывать и тестировать компоненты в изоляции. Это позволяет обеспечить их работу в виде самостоятельных единиц, которые могут быть использованы в приложении. Кроме того, важна и поддержка многократного использования компонентов, и возможность организации общего доступа к ним. Это позволяет тому, кто работает в составе команды над неким крупным проектом, не изобретать колесо, которое, в виде некоего компонента, уже изобретено кем-то из членов команды.
Вот несколько полезных инструментов, которые помогут вам организовать работу над проектами в стиле CDD. В одном из следующих разделов мы поговорим об архитектурах проектов, рекомендованных при практической реализации принципов CDD.
▍Bit: индивидуальная и командная разработка компонентов
Bit — это опенсорсный инструмент, созданный, по существу, для поддержки практического применения методологии CDD. Вот видео о Bit. Этот инструмент помогает разрабатывать компоненты, организовывать совместную работу над ними и создавать с их помощью веб-проекты.
Речь идёт о том, что средствами Bit можно изолировать компоненты, которые разрабатываются в рамках некоего проекта. Скажем — в рамках приложения или библиотеки. Bit поддерживает инструменты командной строки, он помогает организовать инкапсуляцию компонентов со всеми их файлами и зависимостями. Bit позволяет разрабатывать и тестировать виртуальные представления инкапсулированных компонентов в изоляции.
Это означает, что компонент, созданный в рамках приложения, можно оснастить всеми его зависимостями, инкапсулировать и превратить в сущность, которую можно использовать и тестировать за пределами приложения.
Далее, Bit позволяет упаковывать самостоятельные, инкапсулированные компоненты и организовывать их совместное использование с помощью облачных средств. Это позволяет командам, работающим над проектами, пользоваться всеми теми компонентами, которые выложены в общий доступ. Сообщество Bit насчитывает порядка 50 тысяч разработчиков. Их усилиями созданы тысячи опенсорсных компонентов, доступных всем желающим.
Разработка проектов с использованием инкапсулированных компонентов
Благодаря возможностям облачной платформы команды разработчиков могут устанавливать опенсорсные компоненты в свои приложения. Члены команд, кроме того, могут предлагать авторам компонентов идеи по улучшению компонентов, делая это прямо из своей рабочей среды. Bit расширяет возможности Git по отслеживанию и синхронизации изменений исходного кода компонентов в различных проектах. Это даёт разработчикам возможность управлять изменениями и обновлениями компонентов.
Bit хранит полное дерево зависимостей компонентов. Это даёт разработчику возможность узнать о том, как обновление компонента может повлиять на зависимые компоненты, о том, что в проекте может оказаться «сломанным» при внесении изменений в некий компонент. Это означает, что благодаря Bit в распоряжении программиста оказывается полномасштабная среда для организации разработки, основанной на компонентах, позволяющая создавать компоненты, тестировать их и организовывать совместную работу над ними и их совместное использование.
Облачные возможности в CDD
Ещё одна полезная возможность Bit заключается в том, что эта платформа позволяет командам разработчиков не только работать со своими компонентами, используя единый интерфейс, но и использовать чужие компоненты, выложенные в общий доступ, и взаимодействовать с авторами этих компонентов.
Дизайнеры интерфейсов, представители заказчиков проектов, а также программисты могут, в ходе совместной работы над проектами, пользоваться едиными визуальными инструментами. Это сокращает разрыв между дизайнерами и программистами. Причём, надо отметить, что в этой ситуации выигрывают не только дизайнеры и программисты, но и конечные пользователи приложений, которые сталкиваются с меньшим количеством неоднородностей и ошибок. Вот, вот и вот — несколько материалов, посвящённых разным аспектам использования Bit.
▍Разработка и исследование UI-компонентов: StoryBook и Styleguidist
StoryBook и Styleguidist — это среды для быстрой разработки элементов пользовательского интерфейса средствами React. Оба эти проекта представляют собой отличные инструменты для ускорения разработки компонентов.
StoryBook
StoryBook — это среда для быстрой разработки UI-компонентов. Она позволяет работать с библиотекой компонентов, просматривать различные состояния компонентов, заниматься интерактивной разработкой и тестированием компонентов.
Работа в StoryBook
StoryBook помогает разрабатывать компоненты в изоляции от приложения. Это способствует улучшению возможностей по многократному использованию компонентов, улучшает тестируемость компонентов.
С помощью StoryBook можно просматривать компоненты, хранящиеся в библиотеке, экспериментировать с их свойствами в интерактивном режиме. Изменения, вносимые в компонент, сразу же, без перезагрузки страницы, визуализируются. Здесь можно найти некоторые примеры компонентов, созданных в StoryBook.
Существуют различные плагины, которые позволяют ускорить процесс разработки компонентов с использованием StoryBook. Это позволяет сократить время, проходящее между изменением кода компонента и формированием его визуального представления. Надо отметить, что StoryBook, помимо React, поддерживает ещё React Native и Vue.js.
React Styleguidist
Эта платформа поддерживает JavaScript ES6, Flow и TypeScript. Она умеет, без дополнительных настроек, работать с Create React App. Styleguidist обладает возможностями по автоматическому созданию документации к компонентам. Это позволяет данной системе играть роль визуального портала документации к компонентам, работой над которыми занимается некая команда.
Если вам интересны проекты наподобие StoryBook и Styleguidist — то вам, возможно, стоит взглянуть и на проект React Live, разработкой которого занимается компания Formidable.
Разница между StoryBook и Styleguidist
В ходе работы со StoryBook программист пишет «истории» (stories) в JavaScript-файлах. При работе со Stuleguidist он пишет «примеры» (examples) в Markdown-файлах. В то время как StoryBook показывает лишь один вариант компонента за один раз, Styleguidist может вывести несколько вариантов разных компонентов. StoryBook отлично подходит для анализа различных состояний компонентов, а Styleguidist — для формирования документации по компонентам и демонстрации возможностей компонентов.
Архитектурные решения, применяемые при использовании методологии CDD
Работа в стиле CDD означает, что при разработке приложений в первую очередь создают компоненты. При этом такие компоненты должны быть как можно более независимыми друг от друга. Это означает, что разработчик не просто создаёт некий «набор компонентов». Он ещё и реализует так называемую дизайн-систему компонентов пользовательского интерфейса.
Компоненты можно создавать как в рамках самого приложения (то есть — в том же проекте, репозитории), так и в формате отдельного проекта (репозитория) — в виде библиотеки компонентов.
Инструменты наподобие Bit позволяют изолировать и инкапсулировать компоненты. Это даёт разработчику широкие возможности по созданию, тестированию, повторному использованию компонентов, позволяет дорабатывать их где угодно — независимо от того, где именно они были созданы.
Если говорить о том, что применение CDD предусматривает разработку компонентов в виде первого шага работы над неким проектом, то это подразумевает и то, что компоненты стремятся делать подходящими для многократного использования. Это позволяет применять их при создании различных приложений. Поэтому разработчику нужно выяснить то, как именно ему нужно поступать для того, чтобы создавать подобные компоненты. Нет ничего хуже, чем потратить полгода на то, чтобы создать библиотеку, которой, в итоге, никто не будет пользоваться. Подобное, к сожалению, происходит со многими командами.
Зачем создавать библиотеку компонентов?
Буду с вами честен: Git-репозитории не были задуманы с учётом возможности хранения в них кода атомарных компонентов, которые планируется совместно использовать в различных проектах. Для решения этой задачи не подходят и менеджеры пакетов. И то и другое создано, что совершенно понятно, для поддержки репозиториев кода. Компоненты же — это не репозитории.
Совместное использование компонента в различных проектах
Именно поэтому, в том случае, если нужно взять компонент из одного приложения и использовать его в другом приложении, требуется создать новый репозиторий. Для того чтобы избавить себя от ненужной работы по созданию отдельного репозитория для каждого подобного компонента, большинство команд создаёт один совместно используемый репозиторий, предназначенный для хранения 20-30 компонентов.
При использовании инструмента вроде Bit, в библиотеке компонентов, как таковой, необходимости не возникает. Подобные инструменты позволяют загрузить компонент из приложения в облако и внедрять этот компонент в другие проекты. Если сравнить такую схему работы с традиционными репозиториями, то можно сказать, что это — нечто вроде сравнения музыкального компакт-диска и Spotify. Правда, если вам близка идея разработки и использования библиотек компонентов — возможности таких платформ, как Bit и StoryBook, позволят вам работать и с библиотеками.
При проектировании библиотеки необходимо принять несколько ключевых решений. Ниже будут рассмотрены некоторые важные принципы, которые вам в этом помогут. Основной смысл этих принципов сводится к тому, что ваша задача заключается в том, чтобы создавать независимые компоненты. Остальные этапы работы над проектом напоминают сборку конструктора Лего. Если же принцип разработки независимых компонентов не соблюдается — в один прекрасный день можно столкнуться с неприятностями. Неприятности начнутся тогда, тогда, когда кому-нибудь понадобится нечто, отличающееся от того, что присутствует в библиотеке. Собственно говоря, когда такое происходит, команды и перестают пользоваться библиотеками компонентов.
Предположим, вы всё же решили создать библиотеку компонентов. Если так — предлагаем вам несколько советов, которые вам в этом помогут.
7 принципов разработки качественных CDD-ориентированных библиотек
Преимущества, которые даёт командам разработчиков применение CDD
Команды, применяющие принцип CDD, получают преимущества в виде ускорения разработки, повышения уровня многократной используемости кода, в виде улучшения TDD и наличия единообразного интерфейса дизайн-системы.
Программисты могут писать код, имея доступ к уже написанным компонентам и совместно заниматься внесением изменений в компоненты. Разработка новых возможностей или приложений сводится к настройке и расширению базовых компонентов. Это, кроме того, способствует предотвращению возникновения ошибок, которые обнаруживаются лишь в продакшне.
Совместное использование кода означает, кроме прочего, сокращение объёмов кода, который нужно поддерживать. Это позволяет программистам сосредоточиться на создании чего-то нового. Когда приложения разрабатывают, опираясь на компоненты, это стандартизирует работу за счёт того, что все пользуются единой базой строительных блоков приложений. Компонентный подход, кроме того, способствует гибкости работы.
Некоторые команды сообщают о том, что их рабочие процессы стали до 60% быстрее благодаря использованию модульных компонентов, основанных на дизайн-системах, реализованных в виде наборов React-компонентов. Некоторые организации обнаружили, что благодаря внедрению CDD они могут удалить примерно 30% кода из своих кодовых баз.
Компонентный подход внедряют такие компании, как Uber, Airbnb, Shopify и другие.
Итоги
Лично я не удивлён тем, что применение CDD повышает эффективность разработки ПО. По словам Брэда Фроста, автора книги об атомарном дизайне, модульность и композиция — это важнейшие понятия в биологии, экономике, и во многих других областях. Модульность в применении к разработке программного обеспечения даёт скорость, надёжность, простоту разработки. Она способствует многократному использованию сущностей, улучшает тестируемость и расширяемость кода. Модульность даёт разработчику возможность применения композиции при создании сложных систем. Всё это очень хорошо влияет на процесс и на результаты разработки приложений.
Уважаемые читатели! Применяете ли вы методологию CDD при работе над своими проектами?