Или: Как определить границы независимого битового компонента в вашей распределенной кодовой базе.
Вопрос о том, что должно быть независимым компонентом, или как мы должны определить границы компонента, возникает довольно часто, когда разработчики начинают использовать Bit для реализации компонентной архитектуры.
Если вы пропустили слово Bit, то скажу, что Bit — это цепочка инструментов с открытым исходным кодом, которая помогает разработчикам создавать приложения на основе компонентов и совместно работать над компонентами независимо от репозитория git или любых других настроек разработки.
Как вы увидите, те же причины для выбора архитектуры на основе компонентов должны служить критериями для определения границ компонента.
Сопровождение кодовой базы
Поддерживаемая кодовая база — это та, которую разработчики могут легко понять, изменить и расширить с течением времени. Несколько факторов делают кодовую базу удобной для сопровождения. Мы сосредоточимся на двух: удобочитаемости и возможности повторного использования.
1. Удобочитаемость
Битовые компоненты, которые формируют вашу распределенную кодовую базу, представляют собой небольшие несвязанные единицы кода, которые легко понять и осмыслить.
Компонент имеет ID, который является значимым и описательным. Отношение компонента к другим компонентам, зависимостям и иждивенцам ясно и явно.
Изменения в компоненте изолированы и легко просматриваются. Эффекты изменения, внесенного в один компонент, легко предсказать.
Чтобы в полной мере воспользоваться этими преимуществами, важно, чтобы компоненты были небольшими и сфокусированными. Обычно компонент должен представлять собой небольшую группу файлов, состоящую не более чем из нескольких сотен строк кода, с одной ответственностью.
Компонент должен «делать то, что написано на банке», и ничего больше.
Например, компонент netlify-deployer должен обрабатывать только развертывание компонентов приложения в Netlify. Например, он не должен генерировать артефакты развертывания.
Следование соглашениям об описательных именах и разделению ответственности необходимо для получения максимальной отдачи от этого подхода. Это позволяет вам проверять зависимости и иждивенцы, а также понимать взаимосвязь между компонентами, не читая код компонентов. Это приводит к более быстрому и эффективному процессу разработки.
2. Возможность повторного использования
Повторное использование существующего кода и существующих компонентов может снизить сложность и улучшить ремонтопригодность за счет использования проверенных и проверенных решений.
Представьте себе мир, в котором здания и мосты выходят из строя (рушатся) так же часто, как и программные приложения. Этого, к счастью, не происходит. Причина в том, что физические конструкции проектируются и строятся один раз с использованием проверенных и испытанных решений. Они не модифицируются и не расширяются на лету, как программное обеспечение.
Мы не можем перестать модифицировать и улучшать наши программные системы, но мы все еще можем учиться на том, как проектируются и строятся физические структуры.
Чем больше вы повторно используете компоненты, чем больше вы используете «проверенные решения», тем более стабильной и ремонтопригодной будет ваша кодовая база.
Компонент многократного использования — это компонент, который может использоваться в разных контекстах разными компонентами или приложениями. Он должен быть расширяемым и настраиваемым для различных вариантов использования.
Он также должен соответствовать принципу единой ответственности и не включать код, не относящийся к его назначению.
С другой стороны, компонент не должен быть «слишком сфокусирован», чтобы его можно было использовать только в тандеме с другим конкретным компонентом. Например, компонент пользовательского интерфейса «таблица-строка», используемый для отображения одной строки в таблице, будет использоваться не сам по себе, а как часть определенного компонента «таблица».
Если отдельные компоненты часто используются вместе, настолько часто, что они практически неразделимы, они должны составлять один компонент. Это упростит обслуживание, поскольку для обновления одной функции потребуется обработка только одного компонента вместо нескольких.
Примечание. В отличие от традиционных монолитных проектов, компоненты в программном обеспечении, основанном на компонентах, используются не только как «библиотеки», но и составляют целое приложение, от самых элементарных и общих строительных блоков до самых сложных. и бетонные компоненты.
Это означает, что «повторное использование» никогда не должно быть единственным критерием для определения границ компонента.
Независимая доставка и автономия команды
Архитектура, основанная на компонентах, позволяет отдельным разработчикам и командам создавать, поддерживать и поставлять компоненты параллельно, независимо друг от друга.
Каждая команда размещает свои компоненты в Битовой области с определенными разрешениями. Это гарантирует гармоничное, эффективное сотрудничество и предотвращает конфликты.
Компонент, за исключением его зависимостей, должен создаваться и поддерживаться одной командой и, соответственно, одной областью действия Bit.
Например, компонент «форма регистрации», вероятно, не должен включать реализацию раздела «условия и положения» в своих исходных файлах.
Вместо этого этот раздел должен поддерживаться как независимый компонент «юридической» командой/областью организации и использоваться как зависимость командой/областью, которая поддерживает компонент «форма регистрации».
Заключение
В заключение, принятие архитектуры на основе компонентов и использование Bit может значительно улучшить ремонтопригодность вашего процесса разработки, возможность повторного использования и автономию команды.
Сохраняя компоненты небольшими и сфокусированными, придерживаясь принципа единой ответственности и обеспечивая независимую доставку, вы можете оптимизировать свою кодовую базу как для удобочитаемости, так и для повторного использования.
Такой подход поощряет сотрудничество, снижает сложность и приводит к более эффективному процессу разработки. Использование компонентно-ориентированной разработки поможет вашей команде создавать стабильные, удобные в сопровождении и расширяемые программные системы, которые можно будет легко понять, изменить и расширить с течением времени.
