Предыдущие статьи вступительной части:
Введение.
В этой статье я разберу, какие технологии были выбраны для моего проекта и почему.
Также расскажу о том, с какими проблемами столкнулся и как собираюсь их решать в будущем.
Я выбирал инструменты под одну простую задачу - разработать приложение для Windows, чтобы можно было быстро тестировать идеи и получать работающий прототип на привычной платформе.
Часть технологий была мне уже знакома, в то время как с другими предстояло познакомиться с нуля.
Теперь подробно о технологиях.
1. Язык программирования: Python.
Я выбрал Python по двум основным причинам. Главная - я хочу развиваться в машинном обучении, так как мне очень нравится это направление, и Python здесь де-факто стандарт. Вторая причина практическая - у меня уже есть базовое знакомство с языком, и сейчас я хочу вырасти с этого уровня до профессионального.
Основная проблема на данный момент - дефицит времени. Пока я полностью сфокусирован на создании MVP (минимально жизнеспособного продукта), у меня не получается параллельно углублять знание языка. Изучение Python отошло на второй план, хотя без него реализация проекта происходит медленнее.
Планирую в ближайшее время выделять 1-3 часа в день на целенаправленное изучение критически важных для моего проекта тем (например, классы, продвинутые структуры данных). Без этого двигаться дальше будет сложно.
2. База данных: SQLite + SQLAlchemy + Alembic.
Для работы с данными я выбрал связку SQLite (движок БД), SQLAlchemy (ORM) и Alembic (миграции). Это был самый простой и понятный для меня стартовый вариант (по советам из интернета), который подходил для моего проекта.
- SQLite: Предельно прост для начала - вся база в одном файле, который легко контролировать.
- SQLAlchemy: Мощный и удобный ORM, который сокращает количество "сырого" SQL-кода и ускоряет разработку.
- Alembic: Стандартный инструмент для управления миграциями в экосистеме SQLAlchemy, позволяющий контролировать изменения структуры базы.
При разработке я столкнулся с двумя проблемами:
- Ограниченная поддержка ALTER TABLE. SQLite поддерживает только ограниченный набор операций.
- Отсутствие понимания того, как заставить Alembic корректно работать внутри приложения, собранного в exe-файл с помощью PyInstaller. Это ключевой технический барьер, который не позволяет мне начать пользоваться своей же программой.
Я планирую перейти с SQLite на PostgreSQL. Этот шаг, во-первых, решит проблему с ограниченным ALTER TABLE, а во-вторых, станет поводом глубоко изучить SQL, саму PostgreSQL и принципы работы с базами в целом. Отдельно предстоит разобраться, как организовать миграции (возможно, с помощью того же Alembic) в среде собранного приложения.
Это вторая по приоритету учебная цель после углубления в Python.
3. Интерфейс: PySide6 (Qt)
В качестве фреймворка для интерфейса я выбрал PySide6 (Qt для Python).
Хотя я начинал с рекомендованного новичкам tkinter, PySide6 оказался инструментом другого уровня.
Его главное преимущество - Qt Designer, визуальный редактор интерфейсов. Задача, на которую в tkinter я потратил неделю кодирования, в Designer была решена за три дня (включая тонкую настройку стилей). Это несравнимо ускоряет прототипирование.
Дополнительные плюсы: стабильная работа базовых функций (вроде копирования-вставки, с которой были проблемы в tkinter) и возможность применять знания CSS для тонкой стилизации, что делает интерфейс гибким и современным.
На старте пришлось потратить время на освоение не только самой библиотеки, но и парадигмы Qt (сигналы/слоты).
Кроме того, возникла техническая проблема: PyInstaller на первых порах не находил модули PySide6 при сборке в exe-файл, что потребовало дополнительной настройки.
Несмотря на более высокий порог входа, я планирую и дальше использовать PySide6. Опыт с tkinter не прошёл даром - он помог понять базовые принципы построения UI "под капотом".
PySide6 предоставляет богатый профессиональный инструментарий "из коробки" для создания сложных и визуально приятных приложений. Первоначальные затраты времени на обучение окупаются в долгосрочной перспективе.
4. Упаковка кода в приложение: PyInstaller.
Для сборки проекта в исполняемый файл (.exe) я использую PyInstaller. Это стандартный инструмент для дистрибуции Python-приложений под Windows.
На первый взгляд, PyInstaller - самый прямой путь к цели: одной командой упаковать код, зависимости и интерпретатор в один переносимый файл, который можно запустить на любой машине без установленного Python. Это идеальное решение для быстрого создания дистрибутива тестовой версии (MVP) программы.
На практике всё оказалось сложнее. Я столкнулся с двумя ключевыми проблемами:
- Во-первых, мой механизм резервного копирования БД срабатывает при каждом запуске, а не только при миграциях. Из-за этого вместо одного файла данных накапливаются десятки копий.
- Во-вторых, после сборки в exe возникала ошибка ImportError. Целый день ушёл на конфигурацию PyInstaller и рефакторинг кода, пока я не понял, что корень проблемы - в операционной системе. Детально разберу это в отдельном посте.
Пока я не найду стабильный способ конфигурации PyInstaller для работы с внешними ресурсами (как файлы миграций Alembic), сборка останется главным узким местом.
Планирую углубиться в документацию и рассмотреть альтернативы вроде Nuitka.
5. Архитектурный паттерн: MVC.
Я остановился на паттерне Model-View-Controller по простой причине - это стандарт де-факто для десктопных приложений. Вся документация, туториалы и советы опытных разработчиков указывали на MVC или его близкие варианты (MVVM, MVP).
Я выбрал классику (MVC), чтобы на практике освоить фундаментальный принцип разделения ответственности между компонентами.
Первая же попытка внедрить MVC обернулась разочарованием.
Я создал три папки (models, views, controllers), но по сути получил "МVC-подобный" спагетти-код:
- Модели были всем сразу: структуры данных, работа с БД, бизнес-логика.
- Круговые зависимости: модели тянули контроллеры, контроллеры - модели.
- Нулевая тестируемость: Из-за переплетения модулей проверить что-либо по отдельности было невозможно.
Такой подход не принёс улучшений. Код оставался таким же запутанным, просто распределённым по разным папкам.
Прорыв случился, когда я обратился к нейросети и получил схему "чистой архитектуры" с дополнительными слоями - репозиториями, сервисами и сущностями. Только тогда я осознал настоящую силу паттерна.
Основная задача на будущее - углубить понимание паттерна: изучить реальные примеры реализованных приложений, детально разобрать каждый компонент, особенно взаимодействие и внутреннее устройство представления и контроллера. Всё это - после детального освоения Python и технологий базы данных.
Итог.
Вот так выглядит мой текущий технологический набор. Он сформировался не только из осознанного выбора, но и из столкновений с конкретными ограничениями.
Если кратко: интерфейс (PySide6) работает, логика на Python пишется. А вот два блока остаются проблемными:
- Данные: не могу выполнить сложные миграции в SQLite и запустить Alembic в собранном приложении.
- Дистрибуция: не отлажены механизм резервного копирования и сборка в exe под чужие системы.
Именно эти технические барьеры не дают получить готовый к распространению прототип.
Присоединяйтесь.
Подписывайтесь здесь, на Дзене, чтобы не пропустить ни одного отчёта.
А ещё - заходите в мой Telegram-канал. Там я буду делиться сырыми мыслями, скриншотами кода, отвечать на вопросы и многим другим.
Все статьи вступительной части:
- Технологии - почему выбрал именно их и с какими сложностями столкнулся (текущая статья).
7. Планы на ближайшее будущее - на месяц - два (будущая статья).