Борьба с энтропией в процессах разработки программного обеспечения, одна автоматизированная задача за раз

В душе я инженер-программист с 10-летним опытом работы на различных инженерных и управленческих должностях.

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

  • Создается новая кодовая база программного обеспечения
  • Процесс разработки выбран (или спроектирован)
  • На этапе «Медовый месяц» разработчики внимательно следят за процессом.
  • По мере того, как реальность начинает действовать, требования или инфраструктура меняются, и разработчики постепенно отклоняются от процесса, потому что:
  1. Процесс устарел и больше не соответствует действительности
  2. Сжатые сроки, человеческие ошибки и тому подобное заставляют разработчиков пропускать этапы.
  • Теоретически упрощенный процесс на практике становится набором темных заклинаний, полностью понятных только 1 или 2 разработчикам, которые со временем стараются компенсировать это.

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

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

Да, а как насчет того перераспределения ресурсов от HR, привлечения новых разработчиков в середине проекта, которых также нужно обучить негласному процессу, о котором где-то задокументирован только исторический взгляд, что увеличивает стоимость и время, необходимое для на борту?

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

Или ждать?

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

Что, если бы этот способ позволил сопоставить этот разработанный процесс непосредственно с инструментом CLI, который запускает и автоматизирует этапы процесса?

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

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

Введение в метаданные

Meta — это инструмент управления программными процессами.

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

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

Каждый процесс определяется как набор действий. Например, в рабочем процессе git ветки функций действие будет заключаться в запуске новой ветки функций. Еще одним видом деятельности будет выпуск новой версии кодовой базы.

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

Действия также соответствуют командам в CLI, где каждая команда, в свою очередь, будет выполнять программные команды, соответствующие шагам действия. Meta предоставляет для этого большое количество встроенных функций для реализации ваших команд, таких как Git и NPM. Он также полностью совместим с любой командой оболочки.

Что содержится в файле meta.json?

Этот файл содержит различные команды CLI. Все рабочие процессы описаны в этом файле в формате, в основном основанном на ASL.

Он также указывает некоторые переменные конфигурации, которые могут потребоваться рабочим процессам.

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

У этого процесса есть одно действие — выпуск. При выпуске новой версии кодовой базы разработчик должен:

ƒ ƒ

  1. Убедитесь, что репозиторий git не загрязнен (нет ожидающих изменений)
    ƒƒ ƒƒƒ ƒ
  2. Выйти на ветку master
    ƒƒ ƒ
  3. Обновите версию пакета
    ƒƒ ƒ
  4. Отправка на исходный мастер и теги на удаленный
    ƒƒƒƒ ƒ
    ƒƒ ƒ
    ƒƒ ƒ
    ƒƒ ƒ
    ƒƒ ƒƒ

Соответствующий файл meta.json содержит следующее:

{
  "commands": {
    "release": "release"
  },
  "config": {
    "remote": "origin"
  },
  "workflows": {
    "release": {
      "name": "release",
      "input": [
        "releaseType"
      ],
      "definition": {
        "StartAt": "assertClean",
        "Comment": "Commit a release",
        "States": {
          "assertClean": {
            "Type": "Task",
            "Resource": "git:assertClean",
            "Next": "updateVersion"
          },
          "updateVersion": {
            "Type": "Task",
            "Resource": "npm:version",
            "Next": "pushMaster"
          },
          "pushMaster": {
            "Type": "Task",
            "Resource": "git:push",
            "Input": {
              "branchName": "master"
            },
            "$Input": {
              "remote": "config.remote"
            },
            "End": true
          }
        }
      }
    }
  }
}

Затем сгенерированный интерфейс командной строки можно вызвать в той же папке, которая содержит meta.jsonfile:

~/fictitious-project> meta release minor

И он автоматически выполнит шаги, определенные выше.

Если репозиторий грязный, он выкинет и откажется от продолжения.

MetaMaker

Скриншот, который вы только что видели выше, взят непосредственно из MetaMaker, визуального редактора для meta.json файлов.

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

Очень ранний предварительный просмотр

Я выпускаю очень ранний предварительный просмотр меты для ограниченного числа людей.

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

Хотите попробовать? Напишите мне письмо на адрес [email protected]

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