Использование Git trailers, grep и cherry-pick для создания неограниченных комбинаций функций, стеков и платформ.

Чем, по вашему мнению, занимаются профессиональные инженеры-программисты? Работа обычно включает в себя гораздо больше, чем написание кода. Встречи. Обратная связь с пользователями. Исправления ошибок. Проектные решения. Выбор правильных инструментов. Анализ затрат и выгод. Формирование команды. Делегирование. Список можно продолжать.

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

Если вы профессиональный инженер-программист, то с вероятностью не менее 99,99% вы знаете, что такое Git, и, вероятно, используете его почти каждый день. Осязаемая работа, которую вы производите, обычно представляет собой серию коммитов и ответвлений Git. Конечным результатом является текущая версия вашего приложения.

Что если бы у вас был способ пропустить всю эту трудоемкую работу по интеграции, способ выбрать именно те коммиты, которые вам нужны для создания нужного приложения? Именно это мы и делаем.

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

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

Представляем mlcl

Чтобы помочь сделать все это возможным, мы разработали инструмент командной строки под названием mlcl. Он разработан на основе шаблонов и соглашений, которые уже являются неотъемлемой частью ежедневного рабочего процесса почти каждого разработчика, независимо от языка или платформы. Многие команды напоминают команды git, так как в основном используется git под капотом.

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

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

Самым большим плюсом подхода «вишневый выбор» является то, что нет необходимости разрабатывать какой-то сложный фреймворк с системой плагинов или что-то в этом роде. Все, что необходимо — это хороший код и модульные git-коммиты.

Еще один плюс в том, что каждая строчка кода имеет свою цель. Здесь нет лишнего теоретического кода или нагромождения, в котором вам придется копаться. Что вы видите, то и получаете. Площадь поверхности ровно настолько велика, насколько вам нужно, что помогает вам поддерживать простую, предсказуемую ментальную модель.

Как это работает?

Было рассмотрено несколько подходов, но в итоге остановились на самом простом, который работает без дополнительных настроек и полагается только на git.

В Git есть удобная функция, называемая «трейлерами», которая представляет собой строку (или строки) текста в конце сообщений git-коммита. Исторически, официально поддерживался только трейлер Signed-off-by с помощью опции --signoff (или -s), но примерно год назад (начиная с версии 2.14) была добавлена опция --trailer для официальной поддержки любого трейлера. (Для более старых версий вы можете вручную добавить строку(и) в нужном формате). Эти трейлеры предоставляют полезную информацию о коммитах. Например, GitHub ищет специальный трейлер Co-authored-by, который позволяет приписать коммит нескольким авторам, видимым в пользовательском интерфейсе GitHub.

Для баз кода, предназначенных для работы с mlcl, мы используем трейлеры для указания языка, библиотеки, платформы и/или функции, относящейся к коммиту.

Например, мы запустим команду git commit с сообщениями и трейлерами, которая выглядит примерно так:

git commit -m 'enable user authentication' --trailer Molecule='appLanguage=TypeScript, appRenderer=React, userAuthentication=Typical'

Смотрите больше: Посмотрите на коммиты в различных ветках molecule-api и molecule-app!

Каждая ветка mlcl создаётся (по мере необходимости) как объект-хэш различных комбинаций выбора. Это означает, что по мере добавления новых опций количество потенциальных ветвей будет расти экспоненциально. Это также означает, что если вы сделаете тот же выбор, что и другие люди, то при начале работы вы будете клонировать ту же ветвь.

Не имеет значения, в какой ветке находятся исходные коммиты. Есть только два требования:

1. Дата автора для каждого коммита должна быть в необходимом (рабочем) порядке.

2. Каждая интеграция должна разрабатываться самостоятельно, в идеале — в ветке для минимального набора функций. Например, для платёжных платформ Stripe, Apple Pay и Google Pay у каждой есть своя ветка. Если выбрано несколько, они будут автоматически объединены вместе во время сборки.

Примечание: Разработчикам, создающим приложения на основе полученной кодовой базы (баз), не нужно беспокоиться обо всем этом. Вы можете создавать свое приложение и фиксировать код как угодно, если только вы не хотите со временем внести свой собственный вклад. Подробнее об этом позже!

Чтобы собрать каждую базу данных, mlcl выполняет довольно сложную операцию git log --grep для поиска (и сортировки) всех соответствующих коммитов для вашего выбора, а затем запускает git cherry-pick для каждого из них с пользовательскими драйверами слияния Git для автоматического разрешения любых конфликтов.

В настоящее время мы используем только два пользовательских драйвера слияния Git — один для JSON, а другой для всех остальных файлов, используя встроенные в git merge-file опции --diff3 и --union. Мы будем добавлять новые драйверы по мере их необходимости.

При написании кода для различных опций, определенно полезно иметь достаточный опыт работы с Git’ом, чтобы знать, как он будет пытаться объединяться. В редких случаях необходимы комментарии-заместители и статические границы кода, но в целом Git очень умён в том, как он объединяет каждый коммит. Также, вероятно, есть некоторые конфигурации линтинга, которые помогут обеспечить слияние кода. Например, выбираемые элементы массива должны располагаться каждый на своей строке с запятыми.

Стоит также отметить, что история Git’а каждой ветки регулярно перебазируется (перезаписывается), но это необходимо и ожидаемо, поскольку сама история Git’а — это результат, который нам нужен.

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

Что дальше для mlcl?

На момент написания этой статьи, mlcl очень специфичен для Molecule.dev. Одна из краткосрочных целей — обобщить его, доработать и добавить больше команд, чтобы облегчить переход между ветками, проверку необходимых коммитов для добавления функций и исправления ошибок, а также применение изменений ко всем другим соответствующим веткам. Все это уже есть, но это может быть гораздо удобнее для пользователя. Также может быть более эффективный способ выбрать все коммиты сразу, передав пользовательский редактор в git rebase вместо того, чтобы выбирать по одному.

Сейчас публичная версия mlcl запрашивает API Molecule.dev для получения соответствующих коммитов для отбора, но следующая основная версия будет включать все следующие дополнительные команды (взятые и отшлифованные из версии, которую мы используем внутри компании):

• mlcl select --show

Показывает текущий выбор.

• mlcl select --feature=Value

Выбирает нужную ветку для указанной функции (функций), оставляя при этом другие выборки нетронутыми.

Например:

  mlcl select --appThemes=Light

  mlcl select --appThemes=Dark

  mlcl select --appThemes="Light, Dark"

Или несколько функций одновременно:

  mlcl select --appUi=Tailwind --pushNotifications=Enabled --paymentPlatforms="Apple Pay, Google Pay"

• mlcl checkout <hash>

Проверяет известный хэш ветки mlcl и обновляет выделение в соответствии с ним.

• mlcl rebase

Перераспределяет соответствующие коммиты в текущую ветку.

• mlcl rebase --show

Показывает соответствующие коммиты выделения, которые будут перебазированы на текущую ветку.

• mlcl rebase --all

Перераспределяет соответствующие коммиты каждой известной подборки на их соответствующие ветки.

• mlcl rebase --show-all

Показывает релевантные коммиты каждой известной подборки, которые будут перебазированы на соответствующие ветки.

• mlcl rebase --all --continue=<hash>

Если по какой-то причине первоначальный mlcl rebase --all не сработал, вы можете продолжить с определенного хэша, чтобы избежать повторного ребазинга всех предыдущих веток.

• mlcl rebase --all --feature=Value

Перебазирует все известные коммиты для указанной функции (функций) в соответствующие ветки. Полезно для обновления только ветвей, относящихся к конкретной функции (или функциям), чтобы не тратить время на перебазирование незатронутых ветвей.

• mlcl sync [remote]

Синхронизирует каждую ветку с удаленной.

Другими полезными дополнениями могут быть такие, как:

Что будет дальше для Molecule.dev?

Будущее сейчас не определено на 100%, но я хотел бы думать, что это начало чего-то, что может серьезно поднять планку как для разработчиков, так и для конечных пользователей. Долгосрочная идея заключается не только в том, чтобы сэкономить разработчикам безумное количество времени и средств, но и в том, чтобы улучшить наше представление о создании программного обеспечения, сделав его более простым и доступным для всех, чтобы создавать и использовать высококачественные приложения.

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

В конечном итоге (надеюсь, скорее рано, чем поздно), Molecule.dev будет иметь торговую площадку и доску вакансий.

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

• Как продавец: Будь то библиотека пользовательского интерфейса, пакет иконок, шаблоны, база данных, CDN, да что угодно… у вас будет место, где вы сможете продавать свою работу (которая в конечном итоге сводится к git-коммитам, верно?) любому количеству покупателей.

Здесь есть большой потенциал, и совершенствование этих инструментов и практик — дело, которое стоит продолжать. Если вы не согласны, пожалуйста, дайте мне знать! Я с удовольствием выслушаю ваши мысли и отзывы.

Оставайтесь на связи!

Теперь, когда mlcl и assemble.molecule.dev официально работают, посты в инженерном блоге, подобные этому, будут публиковаться чаще, ориентируясь на каждый вторник, или каждый второй вторник, если это не интересный/качественный контент.

В крайнем случае, вы сможете следить за еженедельными обновлениями, подписавшись на сайте assemble.molecule.dev и включив рассылку новостей.

Molecule.dev работает на 100% на собственные средства и хотел бы остаться таким, а это значит, что без вас это невозможно.

Также не забудьте:

• Поделитесь этой статьей в блоге
• Следите за @molecule_dev в Twitter
• Следите за всеми нашими публичными репозиториями на GitHub.

Спасибо за чтение!