Почему современный интерфейсный инжиниринг все больше и больше неотделим от Monorepo?

С ростом сложности интерфейсной разработки некоторые предприятия или библиотеки инструментов обычно включают множество репозиториев.Со временем недостатки разработки нескольких репозиториев становятся все более очевидными, и появился новый метод управления проектами, Monorepo. Эта статья в основном посвященаКонцепция монорепо,Недостатки мультирепо,Преимущества монорепотак же какВысадка МонорепоДавайте разберемся и узнаем о Monorepo с этих точек зрения.В конце статьи будут вопросы для размышления, и все желающие могут активно ее обсудить.

Что такое монорепо?

Monorepo на самом деле не новая концепция, в области разработки программного обеспечения она имеет более чем десятилетнюю историю. Концепция хорошо понятна, т.е.несколько проектовпомещатьскладВнутри наоборот традиционный режим MultiRepo, то есть каждому проекту соответствует отдельный склад для децентрализованного управления.

Современная разработка интерфейсов становится все более и более неотделимой от Monorepo.Будь то бизнес-код или библиотека инструментов, все больше и больше проектов используют Monorepo для разработки. Google предпочел бы поместить весь код в проект Monorepo, а исходный код известных проектов с открытым исходным кодом, таких как Vue 3, Yarn, Npm7 и т. д., также управляется Monorepo.

Общий каталог Monorepo выглядит следующим образом: несколько подпроектов хранятся в пакетах, и каждый подпроект имеет свой собственныйpackage.json:

├── packages
|   ├── pkg1
|   |   ├── package.json
|   ├── pkg2
|   |   ├── package.json
├── package.json

Так в чем же волшебство Monorepo, что делает его таким популярным и популярным?

Боль мультирепо

Чтобы заранее узнать о преимуществах Monorepo, мы должны выяснить, как развивать болевые точки.

традиционный способMultiRepoСреди них каждому проекту соответствует отдельный репозиторий кода. Я тоже развивался таким образом раньше, и я действительно почувствовал многие недостатки, которые приносит этот путь. Теперь я поделюсь с вами по одному.

1. Повторное использование кода

При сопровождении нескольких проектов некоторая логика, вероятно, будет использоваться несколько раз, например, некоторые базовые компоненты, функции инструментов или некоторые конфигурации.Вы можете подумать: почему бы вам не скопировать код напрямую, чтобы избежать проблем?! Но есть проблема в том, что если в этих кодах есть ошибки или нужно внести какие-то коррективы, приходится модифицировать несколько копий, а стоимость обслуживания становится все выше и выше.

Итак, как решить эту проблему? Лучший способ — извлечь общедоступный код логики и опубликовать его как пакет npm.Как только вам нужно изменить его, вам нужно изменить только часть кода, а затем опубликовать его.

Но действительно ли это идеальное решение? Позвольте мне привести пример, такой как вы представили1.1.0Версия пакета А, есть проблема с служебной функцией, нужно сделать следующее:

• 1. модифицировать код полезной функции
• 2. выпускать1.1.1версия нового пакета
• 3. Установите новую версию A в проект.

Это может быть только одна строка кода, которая должна пройти через столько процессов. Однако трудно гарантировать, что на этапе разработки не будет багов, если есть кнопка, которую нужно изменить по стилю, вышеописанный процесс нужно повторить еще раз... Остановитесь и задумайтесь, эти повторяющиеся шаги действительно необходимы? Мы просто хотим повторно использовать код, почему так сложно каждый раз изменять код?

Вышеупомянутая проблема на самом делеMultiRepoUniversal problems, because of the cutting of different warehouse workspace, the cost of multiplexing code is high, the process of development and commissioning is cumbersome, even if people feel crazy in the case of frequent changes in the base library, and the experience is very бедных.

2. Управление версиями

При методе разработки MultiRepo управление версиями зависимых пакетов иногда представляет собой особенно метафизическую проблему. Например, вначале версия инструментария была v1.0.0, и многие проекты зависели от этого инструментария, но в какой-то момент инструментарий выдал ошибку.break changeверсии, которая полностью несовместима с оригинальной версией API. Фактически, некоторые проекты не обновляли эту зависимость, что приводило к необъяснимым ошибкам.

Когда проектов слишком много, легко получить такую ​​ситуацию, что обновление зависимостей будет несвоевременным. Это еще одна болевая точка.

3. Инфраструктура проекта

Потому что в MultiRepo рабочий процесс каждого проекта разделен, поэтому для каждого проекта необходимо настроить среду разработки, процесс CI, процесс развертывания и выпуска и т. д., и даже каждый проект имеет свой собственный набор инструментов для формирования шаблонов.

На самом деле нетрудно обнаружить, что логика многих инфраструктурных проектов в этих проектах повторяется.Если это 10 проектов, то необходимо поддерживать 10 инфраструктурных процессов.Не говоря уже о повторении логики, есть спецификации для строительства, развертывание и выпуск между проектами.В унифицированной ситуации более проблематично поддерживать.

Доход от монорепо

сказать четкоMultiRepoПосле болевой точки, я думаю, вы, вероятно, сможете понять, почему она родилась.Monorepoэта технология. Теперь давайте разберем его подробноMonorepoКакие преимущества это дает современному фронтенд-инжинирингу?

прежде всегоСогласованность рабочего процесса, Так как все проекты размещены на одном складе, очень удобно повторное использование.Если есть зависимое изменение кода, то проект, использующий эту зависимость, сразу это воспримет. И все проекты используют самый свежий код, и не будет ситуации, что другие версии проекта вовремя не обновятся.

С последующимСнижение капитальных затрат проекта, Все проекты повторно используют набор стандартных инструментов и спецификаций без переключения сред разработки.Если есть новый доступ к проекту, вы также можете напрямую повторно использовать существующие инфраструктурные процессы, такие как процессы CI, процессы сборки и выпуска. Таким образом, для обслуживания инфраструктуры всех проектов требуется всего несколько человек, а стоимость обслуживания также значительно снижается.

Более того,Сотрудничество в команде также проще, с одной стороны, все разрабатывают на складе, который может легко делиться и повторно использовать код, а также легко извлекать исходный код проекта. С другой стороны, история git commit также поддерживает отправку по функциям. Ранее для отправки определенная функция, вам нужно изменить несколько репозиториев и отправить несколько коммитов.Теперь вам нужно отправить их только один раз, что упрощает записи коммитов и облегчает совместную работу.

Высадка Монорепо

Если вы никогда не касались разработки Monorepo, вас может смутить этот момент: я только что сказал так много преимуществ Monorepo, но до сих пор не знаю, как его использовать! Достаточно ли переместить весь код напрямую в один репозиторий?

Конечно, нет, в реальных сценариях для падения Monorepo требуется полная поддержка инженерной системы, потому что управление проектами на основе Monorepo — это не только код, который вы можете собрать, но также необходимо учитывать анализ зависимостей между проектами, зависящий от установка, процесс сборки, процесс тестирования, CI и процесс публикации и многие другие аспекты, но также учитывайте проблемы с производительностью после того, как размер проекта достигает определенного уровня, например проект构建/测试слишком долго делатьИнкрементная сборка/тестирование,Выполнение CI по запросуИ так далее, в то же время для достижения всеобъемлющих инженерных возможностей, но также необходимо учитывать проблемы с производительностью.

Поэтому очень сложно настроить полный набор инженерных инструментов Monorepo с нуля. Однако сообщество предоставило несколько более зрелых решений, которые мы можем использовать для настройки или непосредственно для некоторых решений более высокого уровня.

Среди них решения более низкого уровня, такие какlerna, который инкапсулирует базовые функции, такие как установка зависимостей, пакетное выполнение скриптов и т. д. в Monorepo, но нет цепочки инструментов для построения, тестирования и развертывания.Общая функция Monorepo относительно слаба, но часто используется в бизнес-проектах. Инкапсуляция возможностей верхнего уровня обеспечивает поддержку комплексных инженерных возможностей.

Конечно, есть также некоторые интегрированные решения Monorepo, такие какnx(официальный сайт действительно хорош, и там много видеоуроков),rushstack, обеспечивает все возможности процесса от инициализации, разработки, построения, тестирования до развертывания и имеет относительно полную инфраструктуру Monorepo, которая подходит для непосредственной разработки бизнес-проектов. Однако, поскольку различные процессы и цепочки инструментов в этих решениях верхнего уровня уже очень полны, если вы хотите настроить на основе этих решений, стоимость адаптации и обслуживания слишком высока, что в принципе неосуществимо.

Суммировать

В целом, модель развития Monorepo заключается в том, чтобы превратить независимые проекты в единое инженерное целое, решить различные болевые точки в рамках MultiRepo и повысить эффективность исследований и разработок и качество проектирования. В конце концов, у меня все еще есть вопрос: после использования Monorepo для решения предыдущих болевых точек, какие новые проблемы возникли? Можно ли решить эти проблемы? Добро пожаловать для обсуждения в области сообщений.

Эта статья была впервые опубликована в публичном аккаунте «Front-end Sanyuan Classmates», и все желающие могут обратить на это внимание.Оригинальный текст:Почему современный интерфейсный инжиниринг все больше и больше неотделим от Monorepo?

Команде по архитектуре внешнего интерфейса ByteDance IES срочно нужны таланты (p5/p6/p7 много HC), добро пожаловать, чтобы добавить меня WeChat sanyuan0704, чтобы делать что-то вместе.