«Забытые» парадигмы программирования
Получилось так, что те парадигмы, которые раньше потом и кровью пробивались в свет через орды приверженцев традиционных методов постепенно забываются. Эти парадигмы возникли на заре программирования и то, почему они возникали, какие преимущества они давали и почему используются до сих пор полезно знать любому разработчику.
Ладно. Введение это очень весело, но вы его все равно не читаете, так что кому интересно — добро пожаловать под кат!
Императивное программирование
Исторически сложилось так, что подавляющее большинство вычислительной техники, которую мы программируем имеет состояние и программируется инструкциями, поэтому первые языки программирования в основном были чисто императивными, т.е. не поддерживали никаких парадигм кроме императивной.
Это были машинные коды, языки ассемблера и ранние высокоуровневые языки, вроде Fortran.
Ключевые моменты:
В этой парадигме вычисления описываются в виде инструкций, шаг за шагом изменяющих состояние программы.
В низкоуровневых языках (таких как язык ассемблера) состоянием могут быть память, регистры и флаги, а инструкциями — те команды, что поддерживает целевой процессор.
В более высокоуровневых (таких как Си) состояние — это только память, инструкции могут быть сложнее и вызывать выделение и освобождение памяти в процессе своей работы.
В совсем высокоуровневых (таких как Python, если на нем программировать императивно) состояние ограничивается лишь переменными, а команды могут представлять собой комплексные операции, которые на ассемблере занимали бы сотни строк.
Основные понятия:
Порожденные понятия:
— Присваивание
— Переход
— Память
— Указатель
Языки поддерживающие данную парадигму:
Как основную:
— Языки ассемблера
— Fortran
— Algol
— Cobol
— Pascal
— C
— C++
— Ada
Как вспомогательную:
— Python
— Ruby
— Java
— C#
— PHP
— Haskell (через монады)
Стоит заметить, что большая часть современных языков в той или иной степени поддерживает императивное программирование. Даже на чистом функциональном языке Haskell можно писать императивно.
Структурное программирование
Структурное программирование — парадигма программирования (также часто встречающееся определение — методология разработки), которая была первым большим шагом в развитии программирования.
Основоположниками структурного программирования были такие знаменитые люди как Э. Дейкстра и Н. Вирт.
Языками-первопроходцами в этой парадигме были Fortran, Algol и B, позже их приемниками стали Pascal и C.
Ключевые моменты:
Эта парадигма вводит новые понятия, объединяющие часто используемые шаблоны написания императивного кода.
В структурном программировании мы по прежнему оперируем состоянием и инструкциями, однако вводится понятие составной инструкции (блока), инструкций ветвления и цикла.
Благодаря этим простым изменениям возможно отказаться от оператора goto в большинстве случаев, что упрощает код.
Иногда goto все-же делает код читабельнее, благодаря чему он до сих пор широко используется, несмотря на все заявления его противников.
Основные понятия:
— Блок
— Цикл
— Ветвление
Языки поддерживающие данную парадигму:
Как основную:
Как вспомогательную:
— C#
— Java
— Python
— Ruby
— JavaScript
Поддерживают частично:
— Некоторые макроассемблеры (через макросы)
Опять-же большая часть современных языков поддерживают структурную парадигму.
Процедурное программирование
Опять-же возрастающая сложность программного обеспечения заставила программистов искать другие способы описывать вычисления.
Собственно еще раз были введены дополнительные понятия, которые позволили по-новому взглянуть на программирование.
Этим понятием на этот раз была процедура.
В результате возникла новая методология написания программ, которая приветствуется и по сей день — исходная задача разбивается на меньшие (с помощью процедур) и это происходит до тех пор, пока решение всех конкретных процедур не окажется тривиальным.
Ключевые моменты:
Процедура — самостоятельный участок кода, который можно выполнить как одну инструкцию.
В современном программировании процедура может иметь несколько точек выхода (return в C-подобных языках), несколько точек входа (с помощью yield в Python или статических локальных переменных в C++), иметь аргументы, возвращать значение как результат своего выполнения, быть перегруженной по количеству или типу параметров и много чего еще.
Основные понятия:
Порожденные понятия:
— Вызов
— Аргументы
— Возврат
— Рекурсия
— Перегрузка
Языки поддерживающие данную парадигму:
Как основную:
— C
— C++
— Pascal
— Object Pascal
Как вспомогательную:
— C#
— Java
— Ruby
— Python
— JavaScript
Поддерживают частично:
— Ранний Basic
Стоит отметить, что несколько точек входа из всех этих языков поддерживаются только в Python.
Модульное программирование
Который раз увеличивающаяся сложность программ заставила разработчиков разделять свой код. На этот раз процедур было недостаточно и в этот раз было введено новое понятие — модуль.
Забегая вперед скажу, что модули тоже оказались неспособны сдержать с невероятной скоростью растущую сложность ПО и в последствии появились пакеты (это тоже модульное программирование), классы (это уже ООП), шаблоны (обобщенное программирование).
Программа описанная в стиле модульного программирования — это набор модулей. Что внутри, классы, императивный код или чистые функции — не важно.
Благодаря модулям впервые в программировании появилась серьезная инкапсуляция — возможно использовать какие-либо сущности внутри модуля, но не показывать их внешнему миру.
Ключевые моменты:
Модуль — это отдельная именованная сущность программы, которая объединяет в себе другие программные единицы, близкие по функциональности.
Например файл List.mod включающий в себя класс List
и функции для работы с ним — модуль.
Папка Geometry, содержащая модули Shape, Rectangle и Triangle — тоже модуль, хоть и некоторые языки разделяют понятие модуля и пакета (в таких языках пакет — набор модулей и/или набор других пакетов).
Модули можно импортировать (подключать), для того, чтобы использовать объявленные в них сущности.
Основные понятия:
Порожденные понятия:
Языки поддерживающие данную парадигму:
Как основную:
— Haskell
— Pascal
— Python
Как вспомогательную:
— Java
— C#
— ActionScript 3
Поддерживают частично:
— C/C++
В некоторых языках для модулей введены отдельные абстракции, в других же для реализации модулей можно использовать заголовочные файлы (в C/C++), пространства имен, статические классы и/или динамически подключаемые библиотеки.
Вместо заключения
В данной статье я не описал популярные сейчас объектно-ориентированное, обобщенное и функциональное программирование. Просто потому, что у меня есть свое, довольно радикальное мнение на этот счет и я не хотел разводить холивар. По крайней мере сейчас. Если тема окажется полезной для сообщества я планирую написать несколько статей, изложив основы каждой из этих парадигм подробно.
Также я ничего не написал про экзотические парадигмы, вроде автоматного, аппликативного, аспект/агент/компонент-ориентированного программирования. Я не хотел делать статью сильно большой и опять-же если тема будет востребована, я напишу и об этих парадигмах, возможно более подробно и с примерами кода.
Модульное программирование: особенности, примеры, преимущества, приложения
Содержание:
Модуль представляет собой блок операторов, решающий конкретную задачу. Каждый модуль содержит все необходимое для выполнения его собственных функций и может быть отредактирован или изменен, не затрагивая остальную часть проекта.
Этот способ программирования достигается за счет поддержки постоянного интерфейса модуля, который используется другими программными компонентами для доступа к функциям каждого модуля.
Модули устанавливают логические границы между компонентами, улучшая ремонтопригодность. Они включаются через интерфейсы, которые разработаны таким образом, чтобы минимизировать зависимость между различными модулями.
Основные и вспомогательные модули
Основной модуль и несколько дополнительных модулей составляют модульное программирование. Из основного модуля выполняются вызовы функций вспомогательных модулей.
Эти плагины существуют в виде отдельных исполняемых файлов, которые загружаются при запуске основного модуля. Каждому модулю присвоено уникальное имя в операторе PROGRAM.
Рабочие группы могут разрабатывать разные модули по отдельности, не зная всех модулей системы. Каждое модульное приложение связано с номером версии, чтобы обеспечить разработчикам гибкость при сопровождении модуля.
Возможности модульного программирования
Модульность
Компьютеру не нужна сломанная версия кода для его запуска. Человеческие когнитивные ограничения заставляют писать код более мелкими фрагментами.
Программа может содержать другие функции, а также может ссылаться на функции, находящиеся в других файлах. Эти функции или модули представляют собой наборы операторов, которые используются для выполнения операции или вычисления значения.
Чтобы сохранить простоту и удобочитаемость в больших и сложных программах, короткая основная функция используется вместе с другими функциями, а не длинная основная функция.
Разделив программу на группы модулей, каждый модуль будет легче понять, что соответствует основным принципам структурированного программирования.
Определение функции
Функция состоит из объявления ее определения, за которым следуют команды и операторы. Общий вид функции:
Имя_функции (объявление параметра) <
— Объявление параметров представляет информацию, которая передается функции.
— Дополнительные переменные, специально используемые функцией, определены в предложениях.
— Все функции должны включать оператор возврата.
Объем переменных
Переменные, объявленные в основной функции или в пользовательских функциях, называются локальными переменными. У них есть значение при выполнении функции, но их значение не сохраняется после завершения функции.
Переменные, объявленные внешне по отношению к основной программе или пользовательским функциям, называются глобальными переменными. Эти переменные могут быть взяты из любой функции, которая находится внутри программы.
Это процедурный
Модульное программирование достаточно процедурно, поскольку полностью ориентировано на написание кода для функций без учета данных.
Примеры модульного программирования
Модульность в реальной жизни
Представьте себе дом, в котором есть электричество, с несколькими розетками на стенах. Эта система позволяет подключать различные электрические устройства, например, микроволновую печь, стиральную машину, сушилку и т. Д.
Эти устройства предназначены для выполнения своей конкретной задачи при подключении и включении, независимо от того, где они находятся.
Модули приложения должны следовать этой философии. Это означает, что они должны выполнять только свою конкретную задачу независимо от того, в какой части приложения они находятся или даже к какому приложению они подключены.
Кроме того, точно так же, как электрическое устройство можно легко отключить от розетки, модуль должен быть спроектирован таким образом, чтобы его можно было легко удалить из приложения.
Подобно тому, как удаление электрического устройства не влияет на функциональность других подключенных устройств, удаление модулей из приложения не должно влиять на функциональность других модулей этого приложения.
Функции в Java
В Java модули пишутся как независимые функции. Например, у вас может быть функция или блок кода для расчета среднего балла учащегося на основе его оценок на всех курсах, которые они прошли.
Функция должна получить список оценок в качестве входных данных, а затем вернуть вычисленную среднюю оценку:
Эта функция называется CalculateAverageNote. Он получает в качестве входных данных список заметок, используя массив типа данных double, и возвращает вычисленное среднее значение.
В функции сумма локальной переменной инициализируется нулем, а затем с помощью цикла for все уточнения добавляются к сумме. Наконец, полученная сумма делится на количество купюр, возвращая полученное значение.
Если бы во входной матрице были примечания 3.5, 3.0 и 4.0, после их добавления в сумме было бы значение 10,5, а затем оно было бы разделено на 3, потому что есть три примечания. Функция вернет значение 3,5.
Преимущество
Самостоятельное программирование проекта
Несколько программистов могут работать над одним проектом, если он разделен на модули. Разные программисты могут независимо проектировать разные программные модули, что требуется для большой и сложной программы.
Эффективная разработка программ
Программы можно разрабатывать быстрее, поскольку небольшие автономные модули легче понять, спроектировать и протестировать, чем большие программы.
Программист может предоставить необходимые входные данные и проверить правильность модуля, изучив его выходные данные.
Многократное использование модулей
Код, написанный для одной программы, часто бывает полезен для других. Модульное программирование позволяет сохранять эти разделы для будущего использования. Поскольку код можно перемещать, сохраненные модули могут быть связаны с любой другой программой, отвечающей требованиям ввода и вывода.
При монолитном программировании такие участки кода встроены в программу и недоступны для использования другими программами.
Легкость отладки и модификации
Модуль меньше полной программы, поэтому его легче тестировать. Каждый модуль можно написать и протестировать отдельно от остальной части программы. После тестирования модуля его можно использовать в новой программе без повторного тестирования.
Когда программа должна быть изменена, модульное программирование упрощает работу. Новые или отлаженные модули могут быть связаны с существующей программой без изменения остальной части программы.
Недостатки
Чрезмерно объектно-ориентированная структура
В этом программировании используются интерфейсы, что является довольно эффективной идеей. Чтобы воспользоваться этим, некоторые фреймворки поставляются с полным набором взаимозаменяемых классов. Например, для обработки сохраняемости может быть несколько классов, реализующих интерфейс сохраняемости.
Однако интегрированные среды разработки (IDE) не понимают этого. Например, вы можете попытаться найти источник метода, и IDE не будет знать, какой метод вы хотите увидеть, таким образом отображая длинный список файлов, в которых существует метод с таким именем.
Модули слишком маленькие
Есть много модулей, которые содержат только очень маленькую функцию. Каждый модуль требует дополнительного времени на синтаксический анализ и обработку в дополнение к его заголовку в коде.
Следовательно, использование большого количества небольших модулей добавит накладных расходов системе компиляции, увеличивая размер пакета.
Разложить без причины
Некоторые коды почти никогда не меняются. В таких случаях может не иметь большого смысла пытаться сделать его более чистым или с абстрактной логикой, если простое использование уже работает нормально.
Есть коды, которые выглядят не слишком красиво, но они не сильно изменились за последние годы. Нет причин разбирать код, который никогда не менялся и уже нормально работает.
Приложения
Библиотеки компонентов, созданные из отдельно скомпилированных модулей, можно объединить в набор с помощью инструмента программирования, называемого компоновщиком.
Имена функций в разных модулях должны быть уникальными, чтобы облегчить их доступ в случае, если функции, используемые главным модулем, должны быть экспортированы.
Язык C
Модульное программирование можно применять на языке C, потому что оно позволяет устранить большую трудность, разделив его на несколько модулей.
Каждый из этих модулей решает конкретную задачу, а основная программа, представляющая собой набор таких процедур, решает проблему в целом.
Каждая функция, определенная в C, по умолчанию доступна глобально. Это можно сделать, включив файл заголовка, в котором определена реализация функции.
В качестве примера мы хотим объявить тип данных стека, а также то, что реализация и структура данных скрыты от пользователей.
Это можно сделать, сначала определив общедоступный файл с именем stack.h, который будет содержать общие данные с типом данных стека и функциями, поддерживаемыми типом данных стека.
extern int stack_do_something (недействительно);
Теперь вы можете создать файл с именем stack.c, который содержит реализацию типа данных стека:
Ссылки
90 великих цитат Уильяма Шекспира
4 различия между государством и правительством
Структурное и модульное программирование.
Структурное программирование
Структурное программирование — парадигма программирования, в основе которой лежит представление программы в виде иерархической структуры блоков.
По своей сути оно воплощает принципы системного подхода в процессе создания и эксплуатации программного обеспечения ЭВМ.
Структурное программирование воплощает принципы системного подхода в процессе создания и эксплуатации программного обеспечения ЭВМ. В основу структурного программирования положены следующие достаточно простые положения:
Структурное программирование иногда называют еще «программированием без go to». Рекомендуется избегать употребления оператора перехода всюду, где это возможно, но чтобы это не приводило к слишком громоздким структурированным программам.
goto (перейти на) — оператор безусловного перехода (перехода к определённой точке программы, обозначенной номером строки либо меткой) в некоторых языках программирования. В некоторых языках оператор безусловного перехода может иметь другое имя (например, jmp в языках ассемблера).
Фундаментом структурного программирования является теорема о структурировании. Эта теорема устанавливает, что, как бы сложна ни была задача, схема соответствующей программы всегда может быть представлена с использованием ограниченного числа элементарных управляющих структур.
Базовыми элементарными структурами являются структуры: следование, ветвление и повторение (цикл), любой алгоритм может быть реализован в виде композиции этих трех конструкций.
Достоинства структурного программирования:
Модульное программирование
Модульное программирование является естественным следствием проектирования сверху вниз и заключается в том, что программа разбивается на части – модули, разрабатываемые по отдельности.
В программировании под модулем понимается отдельная подпрограмма, а подпрограммы часто называются процедурами или процедурами-функциями. Поэтому модульное программирование еще называется процедурным.
Модуль должен обладать следующими свойствами:
Модули содержат определение доступных для обработки данных, операции обработки данных, схемы взаимосвязи с другими модулями.
Каждый модуль состоит из спецификации и тела. Спецификации определяют правила использования модуля, а тело – способ реализации процесса обработки.
Принципы модульного программирования программных продуктов во многом сходны с принципами нисходящего проектирования: сначала определяются состав и подчиненность функций, а затем — набор программных модулей, реализующих эти функции.
Руководство по разработке, основанной на компонентах
Модульность является одним из ключевых принципов разработки программного обеспечения с 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 при работе над своими проектами?