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

Пройдя все стадии от отрицания до принятия в программировании на Python, могу сказать, что он нам подошел. Но будет неправдой сказать, что нас обошли стороной трудности и проблемы, связанные с особенностями разработки. 

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

Языки и технологии в нашем DWH

Наш DWH облачный и расположен в Google Cloud. Значительную часть технологий этой платформы мы используем для решения задач:

• BigQuery.

• Pub/Sub + Dataflow.

• Dataproc.

• Google Functions.

• Composer.

Помимо этого, есть опенсорсные технологии, которые активно используем — Livy и Presto.

Языки нашей разработки можно представить в виде небольшой таблицы: 

Подружить такое количество технологий с доставкой данных из API и бэкенда требует много усилий. Это выросло в целый проект, позволяющий автоматизировать выгрузки и сбор витрин данных. В качестве основного языка мы используем Python, в узких местах Scala. Проект, предоставляющий простой интерфейс для работы со сложными инструментами, мы назвали de-core.

Что же могло пойти не так?

Кейс 1. Навигация в проекте

В начале проект писали два человека. Со временем команда подросла и встал вопрос, как ориентироваться в коде. 

Проблемы:

• Непонятно, что и где лежит.

• common.py на 10 тысяч строк.

• IDE не помогает найти нужные файлы.

• Документации нет.

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

Что можно сделать:

• Закоммититься на определенную структуру проекта.

• Явно разделить функционал для общего использования и частного процесса.

• Описать базовые классы того, что ожидается от фичи.

• Начать вести документацию. 

• Придумать нейминг.

Первым делом мы выделили «ядро» проекта. Это центральная часть, которая часто переиспользуется и должна быть написана наиболее качественно. Провели глубокий рефакторинг этой части, определили базовые структуры для того, чтобы унифицировать разрабатываемые модули. Ввели понятную структуру в проекте для поддержки ETL-процессов, завязались на нашу архитектуру DWH (raw-, ods-, dds-, cdm-слои), и поиск нужных файлов свелся к логическим единицам — источник и таблица.

Кейс 2. Помоги себе сам

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

Проблемы:

• IDE не подсказывает методы класса.

• Передал аргументы не того типа.

• Нейминг функций/методов/переменных не всегда помогает.

Типизация помогает понять, что ожидает функция или метод, IDE может подсказать атрибуты и методы. А линтеры автоматически проверят эти ожидания. Мы также определили базовые классы как стандарт написания ETL. Поддержка интерфейса классов позволяет быстрее ориентироваться в чужом коде.

Что можно сделать:

• Прописать типы.

• Определить интерфейс ответа функции/метода.

• Подготовить базовые классы.

• Настроить линтеры и хуки.

Кейс 3. Сложная схема зависимостей

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

Проблемы:

• Всегда нужно деплоить проект целиком.

• Трудно вынести часть проекта в отдельную библиотеку. 

• Пакеты зависят друг от друга циклически для разных файлов.

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

Что можно сделать:

• Переразбить проект на пакеты.

• Провести код-ревью и груминг.

• Заложить время на рефакторинг.

Кейс 4. А у меня локально запускается

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

Проблемы:

• Разное поведение локально и на проде.

• Неправильные подсказки от IDE.

Здесь спасает Docker. Все тесты и проверки работы приложения нужно тестировать в виртуальной сред, соответствующей проду.

Что можно сделать:

• Сделать отдельное виртуальное окружение для проекта;

• Запускать тесты только в Docker.

Я пролистал текст, о чем он был?

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

Главное, что стоит держать в голове, начиная большой проект на Python:

• Промышленная разработка на Python — это сложно.

• IDE ваш друг, используйте возможности по максимуму.

• Есть много рекомендаций по тому, как писать код — лучше их изучить.

• Не поскупитесь на автоматизацию, линтеры, хуки, документацию.

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