Мы программируем большую часть нашей жизни.

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

Методологии, которые мы использовали в Google преобразованный как мы и сообщество разработчиков работали. Это популяризировало Магистральная разработка и проверки кода.

Инструменты автоматизированного тестирования и сборки, предлагаемые компаниями CI/CD и службами хостинга Git, также улучшили его.

*Тем не менее, существует слишком много рабочих процессов, практик и инструментов для выбора. *

Удаленная работа, которую мы практикуем с 2011 года, добавляет нерешенных проблем в разработку программного обеспечения.

На протяжении многих лет мы отбирали лучшие практики, которые оказались для нас наиболее эффективными при создании приложений для Android, SDK, платформ SaaS, игр и многого другого.

Результатом является самоуверенный процесс управления кодом и рабочий процесс разработки, который мы внутренне называем «Метод HighFlux».

Мы тратим большую часть времени на кодирование работа в процессев то время как большинство инструментов доступны только после того, как код готов к рассмотрению.

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

Он превратился в git-клиент, написанный на Rust. Но это для другого сообщения в блоге.


Метод HighFlux

TL;DR: метод HighFlux является потомком разработки на основе ствола и предписывает:

  • Используйте монорепозиторий
  • Используйте WIP, а не ветки функций
  • Используйте обратную связь рано и часто

Каждое из вышеперечисленных заслуживает отдельного поста, но вот краткое введение:


Разработка на основе магистрали

Модель ветвления системы управления исходным кодом, в которой разработчики совместно работают над кодом в одной ветке, называемой «магистралью» *, противостоит любому давлению по созданию других долгоживущих веток разработки за счет использования задокументированных методов. Поэтому они избегают ада слияния, не ломают сборку и живут долго и счастливо».

разработка на основе ствола сайт


Используйте монорепозиторий

Предотвращает ад зависимости (в том числе круглые, ромбовидные, конфликтующие и, если вы действительно стары DLL-ад)

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


WIP, а не ветки функций

WIP (незавершенное производство) — это основная рабочая единица. Это недолговечная ветвь со следующими характеристиками:

  • Маленький — Доказано, что небольшие изменения улучшают качество кода и скорость работы команды. Их легче просматривать. Их быстрее проверяют, и их легче тестировать.

    Используйте серию небольших постепенных изменений вместо одного большого изменения.

  • Рядом с багажником — Регулярно (4 раза в день) перебазируйте свою работу поверх свежего ствола.

  • недолговечный — не более 2-3 дней работы в одной WIP.

  • Один WIP на функциональность — объединение несвязанных логических изменений в один WIP затрудняет откат и проверку и тестирование.

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

  • Сливается в ствол атомарно — в результате получается одна фиксация на WIP. История становится чистой и линейной, Легко делимой пополам и откатываемой назад.

  • Всегда виден команде — Возможность просмотра написанного кода любым членом команды прямо сейчас изменило нашу работу. Это способствует владению кодом и знакомству со всеми, а также помогает нам быть более эффективными: писать правильный код, лучше, быстрее.


Ранняя и частая обратная связь

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

    Небольшие группы подготовки к производству, работающие над MVP, особенно там, где у каждого инженера есть своя область, такая как интерфейс и серверная часть, также могут найти это полезным.

  • Начало работы над функцией — самое критическое время для ее проверки.

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

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

  • Проверяйте результат, а не только код — Работающий продукт: UI, CLI.

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

  • При просмотре чужой работы

    • Проверка кода должна быть приоритетной задачей.
    • Сосредоточьтесь на важных вещах — дизайне, алгоритме, эффективности, точности, корректности, а НЕ на стиле кода, опечатках или линтинге. Последние должны быть хуками перед отправкой, определенными для всех товарищей по команде.
  • Некоторое из вышеперечисленного невозможно выполнить с помощью существующих инструментов обзора.


Как практиковать?

Некоторым приведенным выше практикам легко следовать, а некоторые требуют настройки, автоматизации и более структурированных, продуманных инструментов.

Вот список необходимого нам функционала. Часть из них мы уже построили.

  • Каждое изменение кода является частью WIP — нет «индексной» или «промежуточной» области. Это спорная тема, которая представляет собой настоящую проблему. В целом, мы считаем, что преимуществ больше, чем недостатков.
  • *Быстрое переключение между WIP *— это важно для «одного коммита на функциональность», «проверки продукта, а не только кода» и «предоставления ранней и частой обратной связи».
  • Когда переключение между WIP становится простым, это позволяет нам быстрее реагировать на запросы на проверку и исправление.
  • *Легко перемещайте куски кода и файлы между WIP *
  • **Функция синхронизации, которая держит все близко к стволу: **извлечение из ствола и перебазирование всех WIP при новых изменениях. (бонус: предотвращение и обнаружение конфликтов).
  • Непрерывно отправлять весь код в службу хостинга git. чтобы каждый (включая машины!) мог просматривать незавершенную работу заранее и часто.
  • **Возможность запустить «автоматизированную раннюю обратную связь» для всех членов команды. **Включая форматирование и анализ кода перед отправкой, постоянную проверку безопасности и соответствия требованиям во время написания кода, и все это до того, как PR будет готов.
  • Показатели размера незавершенного производства (Эй! У тебя слишком большой WIP) и Проверяйте показатели времени (Эй! Вы должны просмотреть этот код сейчас), чтобы гарантировать, что WIP не станут слишком большими.
  • Поддержка потока предварительных обзоров и потока специальных обзоров..
  • Непрерывная история — Свободно вернуться назад или вперед во времени.


Что дальше?

Это работа в процессе, и нам еще многое предстоит охватить.

Если вы увлечены этим, как и мы, и хотите поделиться своими мыслями и узнать больше о наших — присоединяйтесь к нам. разлад сервер.

Мы надеемся расширить сообщество вокруг метода HighFlux и донести этот более продуктивный способ работы до масс.


Мы (Уве, Матийс а также Парень) по профессии и увлечению являются инженерами-программистами. Мы познакомились в Google и с тех пор основали собственные компании.

На протяжении всей нашей карьеры мы чувствовали, что нам нужна четко определенная структура для разработки программного обеспечения, которая повышает скорость, производительность и удовольствие.

Вот почему последние несколько месяцев мы были заняты созданием git-клиента HighFlux.

Мы используем метод HighFlux для создания git-клиента HighFlux, который теперь доступен для скачать.