2-2 · Глава 2 · 4 мин. чтения

От идеи к коду: первый шаг в доставке программного обеспечения

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

От идеи к коду: первый шаг в доставке программного обеспечения

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

Разработчик печатает, тестирует, дорабатывает и наблюдает за результатом на своём экране. Всё работает. Кнопка появляется там, где нужно. Данные загружаются корректно. Функция делает то, что должна.

Это похоже на прогресс. И это действительно прогресс. Но код, работающий на ноутбуке, ещё не готов к поставке.

Ловушка локального окружения

Когда код живёт только на машине разработчика, он работает в изоляции. Установленные библиотеки, версия операционной системы, конфигурация базы данных, даже номера портов — всё это специфично для конкретного ноутбука. Другой разработчик в той же команде может использовать Python 3.11, когда у вас 3.10. Он может работать с PostgreSQL 15, а вы — с 14. Версия Node у него может отличаться. Пути к файлам точно будут разными.

Эти различия незаметны во время локальной разработки. Код работает на вашей машине, поэтому вы предполагаете, что он работает везде. Но как только кто-то другой пытается его запустить, всплывают проблемы. Библиотека не установлена. Конфигурация указывает на локальный путь, которого нет на другой машине. Несовместимость версий зависимостей вызывает cryptic-ошибку.

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

Пишем код, который путешествует

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

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

Например, Node.js-проект объявляет свои зависимости в файле package.json:

{
  "name": "my-app",
  "version": "1.0.0",
  "dependencies": {
    "express": "4.18.2",
    "pg": "8.11.3",
    "lodash": "4.17.21"
  },
  "devDependencies": {
    "jest": "29.7.0",
    "eslint": "8.56.0"
  }
}

Вторая дисциплина — разделение конфигурации. Адреса баз данных, API-ключи, пути к файлам и настройки, зависящие от окружения, никогда не должны быть жёстко закодированы в исходных файлах. Они должны находиться в переменных окружения или конфигурационных файлах, загружаемых во время выполнения. Так один и тот же код может работать на ноутбуке разработчика, тестовом сервере и в продакшене без изменений. Меняется только конфигурация.

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

Коммиты создают историю. Позже, когда код работает в продакшене и что-то ломается, эта история становится первым местом для поиска. Кто что изменил? Когда? Зачем? Сообщение коммита должно отвечать на эти вопросы.

От локального к общему

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

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

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

Разрыв между работающим и готовым к поставке кодом

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

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

Практический чек-лист перед отправкой кода

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

Все ли зависимости записаны в конфигурационном файле, который можно установить автоматически?
Отделены ли значения, зависящие от окружения (URL базы данных, API-ключи, пути), от кода?
Содержит ли коммит одно логическое изменение со всеми связанными файлами?
Объясняет ли сообщение коммита, что изменилось и почему?
Запускали ли вы код в чистом окружении, соответствующем тому, что будет на сервере?

Если на все пять вопросов вы ответили «да», код готов покинуть ваш ноутбук.

Что дальше

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

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