Ускорьте итерации в коде: советы и практики разработки

Узнайте, как стать более эффективным программистом с помощью локального тестирования.

Делиться

При разработке кода часто необходимо тестировать его перед отправкой в среду разработки или продакшена. Однако ожидание развертывания с помощью GitHub Actions или развертывания CDK Stack с помощью CDK отнимает много времени.

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

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

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

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

Почему необходимо запускать код локально

Во-первых, я хочу объяснить, почему нам необходимо запускать код локально. Простой ответ таков:

Скорость итераций — один из важнейших аспектов для эффективного внедрения работающего кода в продакшн.

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

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

Вместо этого вам следует запускать свой код локально. Например, если вы работаете с IaC, таким как AWS CDK, вы можете создавать и запускать образы Docker локально, по сути, воспроизводя производственную среду, но на своем собственном компьютере. Таким образом, цикл итераций становится простым, а время, необходимое для создания образа Docker и запуска кода, сокращается.

Сборка образа Docker обычно происходит очень быстро, поскольку Docker кэширует предыдущие сборки. Таким образом, большая часть времени, вероятно, будет потрачена на запуск кода с тестовыми входными данными и проверку соответствия выходных данных ожидаемым.

Если вы работаете над веб-приложением, вам следует (и, вероятно, вы уже это делаете) запускать приложение локально перед развертыванием кода. При работе с IaC (инфраструктура как код) разницы быть не должно.

Как осуществлять локальное развитие, как если бы это была производственная среда.

Важный аспект при локальной разработке — это возможность максимально точно воспроизвести производственную среду. Если вы пишете код как инфраструктуру (IaC), создаёте образы Docker и запускаете образ Docker локально:

Вы тестируете с тем же самым кодом, с теми же путями ввода, и если вы скопируете свой файл .env в файл .env производственной среды, вы также скопируете все переменные. Таким образом, запуск образов Docker локально — это оптимальный вариант, если у вас есть такая возможность.

Создавайте локальные скрипты с помощью агентов кодирования.

До появления таких инструментов для программирования, как Cursor и Claude Code, настройка кода для локального запуска обычно представляла собой утомительную задачу. Необходимо было правильно собрать образ Docker, настроить его запуск с помощью файла .env и так далее. Или же можно было захотеть запустить код локально в качестве сервера FastAPI, в этом случае возникали аналогичные проблемы.

Однако сейчас это уже не проблема. Для запуска локально я обычно даю Cursor следующую инструкцию:

Создайте для меня скрипт оболочки, который позволит запускать этот код локально. Скрипт должен запускать образ Docker и иметь необязательный флаг —build, который собирает образ Docker перед его запуском. Образ Docker должен загружать переменные окружения из файла .env.

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

Кроме того, следующие факторы позволяют мне легко запускать скрипт:

• Я никогда не храню сами секреты в файле .env. Я храню только ссылки на секреты, которые мой код затем получает из AWS Secrets Manager. Таким образом, я могу загрузить свой файл env, не опасаясь утечки секретов. Кроме того, это упрощает запуск скриптов для других пользователей при загрузке кода из GitHub.
• Я создаю ещё один файл с тестовыми событиями, куда я могу легко отправлять события запущенному образу Docker. Таким образом, я могу легко проверять входные и выходные данные.
• Я размещаю тестовые скрипты в Git, чтобы все остальные тоже имели к ним доступ. Это включает в себя и файл env, как уже упоминалось, поскольку он не содержит никаких секретов.

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

Я рекомендую настроить локальные тестовые скрипты для всех ваших репозиториев и загрузить их в Git для совместного использования. Доступ к этим скриптам повысит эффективность работы всей вашей команды программистов.

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

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

• Запустите и протестируйте образ Docker с помощью pre-commit hooks.
• Предоставьте своему агенту по программированию доступ к этим скриптам.

Предварительные хуки фиксации изменений

Предварительные хуки (pre-commit hooks) — это код, который выполняется перед каждым коммитом в Git. Типичные примеры предварительных хуков включают:

• Используйте черный цвет для форматирования.
• Для обеспечения типобезопасности запустите mypy.
• Запустите тесты pytest, чтобы убедиться, что все тесты пройдены успешно.

Наличие хука pre-commit гарантирует, что вы никогда не забудете выполнить какие-либо подобные команды перед отправкой кода. Это невероятно полезно и значительно экономит время. Мне трудно сосчитать, сколько раз я забывал запустить форматирование текста перед отправкой, и тесты развертывания в итоге проваливались через 5 минут, что отнимало у меня много времени.

Если сборка, запуск и тестирование образа Docker не занимают слишком много времени, я рекомендую добавить это в хуки pre-commit. Таким образом, вы гарантируете, что перед отправкой кода вы проверите его работоспособность в производственной среде и получите ожидаемый результат для заданных входных данных. Внедрение этого в качестве хука pre-commit, вероятно, сэкономит вам много времени в будущем.

Предоставьте курсору доступ к тестовым скриптам.

Второй совет: я всегда предоставляю Cursor и Claude Code доступ для запуска моих тестовых скриптов. Затем я указываю Cursor запустить тестовые скрипты после внесения изменений и перед завершением текущей реализации.

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

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

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

Заключение

В этой статье я рассказал, как можно создавать реалистичные производственные среды локально, используя скрипты для сборки, запуска и тестирования образов Docker. Это снижает скорость итераций, что является критически важным компонентом эффективной работы программиста. Кроме того, я описал, как я делаю это на практике: я задаю Cursor задачу создания тестовых скриптов и несколько примеров событий, которые я могу запустить на образе Docker. Затем я предоставляю Cursor и Claude Code доступ к запуску этих скриптов, что значительно повышает эффективность моего программирования.

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

👉 Мои бесплатные ресурсы

🚀 Десять раз повысьте свой инженерный уровень с помощью магистратуры (бесплатный 3-дневный курс по электронной почте)

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

💻 Мой вебинар по языковым моделям зрения

👉 Найдите меня в социальных сетях:

📩 Подпишитесь на мою рассылку

🧑‍💻 Свяжитесь с нами

🔗 LinkedIn

🐦 X / Twitter

✍️ Средний

Источник: towardsdatascience.com