Не так давно многие из нас таскали чемодан подозрительного вида на заднем сиденье наших машин или прятали один под нашими кроватями. У некоторых из нас были башни, сделанные из Икеи, с несколькими складскими помещениями, гордо стоящими в наших гостиных. В обоих случаях это стало результатом нашей впечатляющей коллекции музыкальных компакт-дисков. Сегодня, скорее всего, они хранятся в нашем гараже с ностальгией.
После непродолжительного правления музыкальные компакт-диски были заменены iTunes и YouTube с MP3-плеерами между ними. Эта революция произошла в основном из-за 5 основных недостатков компакт-дисков с первого дня:
- Они были громоздкими в использовании, переноске и обращении.
- На их покупку / создание потребовалось слишком много усилий.
- Их было очень сложно изменить и доработать. Никто не хотел записывать новый компакт-диск всякий раз, когда выходила новая песня Бибера (не судите меня).
- Они заставили нас взять с собой кучу песен, которые мы не слушаем, и пролистать их, просто чтобы послушать одну песню, которую мы действительно хотели послушать.
- Кто запомнил, какие песни на каком диске? В любом случае 90% моих записанных компакт-дисков содержали одни и те же 10 песен.
Удивительно, но это не так уж и отличается от того, как мы делимся кодом сегодня, между проектами и людьми. Посмотрим как.
Как это, черт возьми, похоже на совместное использование кода?
Модульность всегда была святым Граалем разработки программного обеспечения и ключом к лучшей возможности повторного использования, ремонтопригодности и тестируемости.
Каждый день все больше приложений, которые мы создаем, разрабатываются с большей модульностью за счет меньших компонентов кода. Многоразовые функции, пользовательский интерфейс и веб-компоненты (такие как React, Vue и Angular), модули Node.js, API GraphQL и даже бессерверные функции являются нашими строительными блоками.
А теперь давайте будем честными - кто точно знает, какие повторно используемые компоненты были написаны в их кодовой базе, упорядочивает их и делится ими между своими проектами в любом масштабе? Я знаю, что не знал. Затем я начал спрашивать себя, почему бы и нет.
Позволь мне показать тебе. Вот приложение React Movie, размещенное на GitHub. Как видите, в нем 49 файлов и 14 каталогов. Один из этих каталогов - подкаталог components. Внутри этого подкаталога есть 8 повторно используемых компонентов React (таких как hero и navigation).
├── src │ ├── App.js │ ├── App.scss │ ├── App.test.js │ ├── components │ │ ├── hero │ │ ├── hero-button │ │ ├── item │ │ ├── list-toggle │ │ ├── logo │ │ ├── navigation │ │ ├── title-list │ │ └── user-profile │ ├── favicon.ico │ ├── global.css │ └── index.js └── yarn.lock
Допустим, у меня есть другое приложение React, и я хочу использовать свой hero компонент в этом другом приложении, а также сделать его доступным для обнаружения моей командой для использования в своих проектах и легко изменить его в соответствии со своими потребностями.
Копирование кода - это очень плохая идея. Это может показаться быстрым способом сделать это, но на самом деле это не так. Не делай этого.
На сегодняшний день у меня действительно есть три варианта:
- Опубликовать девять пакетов. Создайте восемь новых репозиториев, шаблонов, опубликуйте девять пакетов и измените исходный код обоих проектов на требовать их. Когда я хочу изменить компонент, мне придется очень много работать, чтобы внести изменения из разных репозиториев. А теперь представьте, что у вас их 500.
- Я могу использовать Lerna для хранения нескольких пакетов в одном репо, но это работает, только если я действительно хочу перейти на монорепозиторий. Даже в этом случае мне придется реструктурировать свой проект, настроить каждый пакет отдельно и определить их зависимости, и каждое изменение все равно будет проходить через исходный репозиторий.
- Общая библиотека: создайте новое репо, сгруппируйте компоненты вместе, создайте конфигурации, необходимые для такого проекта, опубликуйте его как новую библиотеку и измените исходный код обоих проектов. Каждое приложение, использующее эту библиотеку, будет добавлять избыточный код, вес и сложность. Каждая модификация требует переиздания всей библиотеки и проходит через владельца.
Дело в том, что пакеты отлично подходят для крупных проектов. Для небольших компонентов и модулей эти решения имеют те же проблемы, что и музыкальные компакт-диски: серьезные накладные расходы, сложные изменения и отсутствие возможности обнаружения.
В некотором смысле настройка 500 репозиториев и пакетов для совместного использования более мелких компонентов напоминает мне использование проигрывателя мини-дисков (не самые лучшие из моих потраченных 100 долларов): вы не можете решить эту проблему путем его оптимизации. Вы должны вводить новшества.
Итак ... iTunes для общего кода?
Очевидно, что сравнение общих библиотек с компакт-дисками не очень точно технически. Сложность совместного использования функциональных возможностей между сложными средами и контекстами отличается от сложности прослушивания Леди Гаги.
Тем не менее, совместное использование общего кода между проектами на самом деле не должно быть таким сложным. Что мы действительно можем узнать из того, как мы делимся и потребляем музыку сегодня, так это то, что для эффективного обмена требуется лучшее взаимодействие: сокращение накладных расходов, повышение доступности и переход от статического к динамическому.
Итак, мы решили построить его
Где-то в начале 2017 года нам приснился именно этот сон. Одна из лучших черт открытого исходного кода заключается в том, что наличие идеи - вполне достаточная причина для ее создания.
Мы решили пойти дальше и создать Bit - проект с открытым исходным кодом, предназначенный для совместного использования кода тем же, что и iTunes для обмена музыкой - сделать его простым, динамичным и легко доступным для всех. Идея Bit проста: избавьтесь от накладных расходов, связанных с совместным использованием кода.
Как это работает
Он был создан для обеспечения максимально возможной скорости «управляемого копирования и вставки» и на 100% совместим с Git и NPM.
Ключ кроется в способности Bit отделить представление общего кода от файловой системы вашего проекта, а также в его способности отслеживать общий код в репозиториях и проектах, независимо от того, установлен ли он или фактически получен в этих проектах.
Это устраняет накладные расходы на совместное использование кода, устраняя необходимость разделения ваших репозиториев или необходимости реструктуризации вашего проекта и создания шаблонных нескольких пакетов внутри него.
Вместо этого вы можете просто указать Bit на любую часть вашего репо, которой вы хотите поделиться, позволить Bit автоматически изолировать ее (включая зависимости) и поделиться ею в общем месте под названием Scope, из которого ее можно установить с помощью NPM.
Поскольку Bit может отслеживать фактический исходный код между проектами, вы также можете использовать его для импорта самого кода в любой репозиторий, изменения его и позволить Bit синхронизировать изменения в ваших проектах за вас.
При совместном использовании вы даже можете eject вернуть код обратно в зависимость от пакета для вашего проекта.
В результате практически отсутствуют накладные расходы на совместное использование кода и его доступность с помощью NPM, повышается обнаруживаемость и упрощается обслуживание. Области видимости даже помогают создавать и тестировать ваш код, поэтому вам не нужно настраивать эти среды для каждого пакета.
Вот как выглядит Bit’s workflow:
- Установите Bit и инициализируйте его для своего проекта.
- Выберите, какие компоненты кода нужно отслеживать в вашем проекте и какие среды добавить для процессов сборки и тестирования.
- Поделитесь ими с удаленной областью действия, где они размещены, организованы и доступны для установки с помощью вашего любимого диспетчера пакетов.
- Легко импортируйте их код в любое репо, изменяйте его по мере необходимости и обновляйте свои изменения во всей кодовой базе.
Давайте посмотрим на пример.
Вернуться к фильму React
Вернемся к React movie-app.
Добавление Bit в проект позволило мне отслеживать и изолировать компоненты многократного использования внутри, без создания новых репозиториев или изменения кода моего проекта. Затем я отправил их в эту коллекцию.
На то, чтобы поделиться им, потребовалось совсем немного времени, а мой проект вообще не изменился. Не было создано новых package.json файлов, и мне не пришлось настраивать несколько сред или бороться с моим деревом зависимостей.
Как видите, каждый компонент теперь доступен всей моей команде для установки с помощью NPM или импорта в свои собственные проекты для дальнейших модификаций.
Они могут искать его и просматривать полезную информацию - от рендеринга в реальном времени до результатов сборки и тестирования, автоматически анализируемой документации и примеров - чтобы судить о ее полезности.
Теперь вся наша команда может организовывать и совместно использовать наши общие компоненты кода без необходимости ежедневно усердно работать или изобретать велосипед.
После более чем 10-месячного использования и использования другими командами и сообществами, я приветствую вас присоединиться и использовать его в своих проектах.
Вы можете посмотреть видео-демонстрацию этого проекта здесь.
Назад в будущее
Еще несколько лет назад нам приходилось записывать новый проект для каждой песни, которую мы хотели послушать. Нам приходилось хранить и поддерживать несколько статических компакт-дисков и тащить за собой кучу вещей, чтобы просто послушать одну песню. Мы дублировали песни между компакт-дисками, и у нас возникли проблемы с поиском песен, которые мы действительно хотели.
iTunes предоставил нам динамичный опыт, который помог нам составлять и обмениваться плейлистами, легко находить нужные песни и быстро обновлять наши плейлисты. Когда я на вечеринке, я могу легко включить свой быстрый летний плейлист или так же легко сыграть свои романтические песни моей кошке, чтобы она заснула.
Мы можем многое узнать из того, как музыка перемещалась с компакт-дисков в общие списки воспроизведения. Bit стремится сделать совместное использование кода и повторное использование простым и доступным для всех, как это сделал iTunes для общей музыки. Работа над ним все еще продолжается, и поэтому ему еще есть куда расти и развиваться. Приглашаем вас попробовать, предложить идеи и отзывы и помочь нам сделать этот скачок вперед.
«Секрет эффективного создания« больших »вещей состоит в том, чтобы вообще не строить их. Вместо этого скомпонуйте большую вещь из более мелких и целенаправленных частей… »
- А. Османи
