Почему глобальные переменные это плохо?
Глобальные переменные считаются плохой практикой почти во всех проектах (включая автотесты) по нескольким причинам:
1. Нарушение принципа Single Responsibility
Функция или класс начинают зависеть от внешнего состояния, которое не очевидно из их параметров.
Код сложнее понять, потому что поведение меняется неявно.
Пример:
counter = 0 # глобальная переменная
def increment():
global counter
counter += 1
Вызов increment()
меняет глобальное состояние, и понять, почему counter
стал, например, 42, будет сложнее.
2. Трудно отлаживать и тестировать
Любой участок кода может поменять глобальную переменную в любой момент.
При отладке приходится искать, кто и где изменил значение.
В юнит-тестах такие переменные сложно изолировать.
3. Проблемы с многопоточностью и асинхронностью
Если два потока или корутины изменяют глобальную переменную одновременно — возможны гонки данных (race conditions).
Для потокобезопасности придётся использовать блокировки, что усложнит код.
4. Плохая переиспользуемость кода
Функция, завязанная на глобальные переменные, не универсальна — её нельзя легко перенести в другой проект.
Такой код сложно сделать модульным.
5. Нарушение принципа Dependency Injection
Вместо того чтобы передать нужные данные через параметры функции или конструктора класса, код “магически” использует глобалку.
Это затрудняет понимание и поддержку.
6. Склонность к “магическим багам”
Значение глобальной переменной может измениться “по пути” вызова функций, и это приведёт к трудноуловимым ошибкам.
Когда глобалки допустимы
Константы (имена в UPPER_CASE)
API_URL = "https://api.example.com" TIMEOUT = 5
Настройки, которые не меняются в процессе работы программы (например, версия приложения).
💡 Вывод: глобальные переменные делают код непредсказуемым, сложным для отладки и тестирования. Лучше передавать данные через параметры, использовать классы, конфигурационные объекты или dependency injection.
Last updated
Was this helpful?