Best practices
Тема дорожной карты · Bash
Лучшие практики Bash начинаются с трёх защитных флагов shell-скриптинга: set -euo pipefail. Эти флаги предотвращают скрытые баги в скриптах автоматизации Linux. set -e завершает выполнение скрипта при возникновении ошибки, set -u трактует неустановленные переменные как ошибки, а set -o pipefail распространяет ошибки в конвейерах. Эти флаги вместе создают надёжную основу для написания стабильных скриптов.
Всегда заключайте переменные в кавычки: "$var" и "${arr[@]}" для защиты от word splitting и glob expansion, вызывающих трудновоспроизводимые сбои. Используйте [[ ]] вместо [ ] для условий в Bash, что обеспечивает более надёжное и гибкое сравнение. Предпочитайте $(...) обратным кавычкам для подстановки команд, так как это упрощает чтение и поддержку кода. Объявляйте локальные переменные функций через local, чтобы избежать нежелательных изменений глобальных переменных.
Запуск shellcheck для каждого Bash-скрипта автоматически выявляет распространённые ошибки, а короткие функции с одной ответственностью упрощают тестирование и обслуживание. Следование этим практикам создаёт надёжные, читаемые и безопасные скрипты автоматизации для продакшн-сред Linux.
Как это работает
Best practices: set -euo pipefail + IFS=$'\n\t' сверху, shellcheck на каждый скрипт, кавычки на переменных, функции, логирование в stderr с timestamps, валидация input, exit с осмысленными кодами (0 = успех, 1+ = конкретные ошибки), документ usage в header-комменте, Google Shell Style Guide. Скрипты — это код: version control, code review, тестирование (bats-core или shunit2 для unit-тестов).
Когда применять
Best practices с первого дня — ретрофит потом означает пересмотр каждого скрипта. Для командных скриптов договоритесь о стиле (Google разумен). pre-commit-hooks — для автоматического shellcheck. Для критичных скриптов пишите bats-core unit-тесты; для deploy-скриптов сначала integration-test в staging.
Типичные ошибки
Ловушки Best practices: пропуск shellcheck ("я достаточно опытен"); скрипты, которые никто не может поддерживать (нет комментариев, нет usage); bash для задач, где Python/Go подошли бы лучше; не тестируете скрипты до production-запуска.