Локальный ассистент для Zoom: план из семи пакетов, пока только один реализован
Автор делится опытом рефакторинга монолитного кода (29 000 строк) в модульный проект с семью планируемыми пакетами и объясняет, зачем это нужно для тестов и масштабируемости.
В статье «Локальный ассистент для зумов, часть 7: семь пакетов в плане, один в коде» (Habr AI, 19 сентября 2026) разработчик рассказывает о переходе от монолитного репозитория к модульной архитектуре. До рефакторинга в папке src/ находилось 29 000 строк кода, распределённых по ~60 файлам, но ни один из них не был оформлен как отдельный пакет. pyproject.toml содержал пустой список модулей, и всё приложение запускалось из корня репозитория.
Автор решил разбить проект на семь логически независимых пакетов. На момент написания реализован лишь один – «поиск по графу встреч». Этот пакет объединяет несколько сложных компонентов: графовые ссылки между узлами, русскую морфологию, досье по людям и системам, а также интеграцию с он‑лайн записью звука, диаризацией и onnxruntime для инференса.
Главная цель рефакторинга – не эстетика, а практичность: чётко определённые границы позволяют писать автотесты, а не полагаться на память разработчика. Модульность упрощает CI/CD, облегчает замену компонентов (например, заменить onnxruntime на более новую версию) и повышает читаемость кода.
В статье также обсуждаются сложности: необходимость согласования схем данных между пакетами, настройка локального репозитория пакетов и поддержка совместимости версий. Автор подчёркивает, что даже если в начале будет только один готовый пакет, такой подход закладывает основу для дальнейшего масштабирования ассистента.
Ссылка на оригинал: https://habr.com/ru/articles/1087172/
Для AI‑разработчиков и студентов такой переход – отличный пример, как превратить громоздкий прототип в поддерживаемый продукт. Модульность ускорит тестирование, упростит интеграцию новых моделей и снизит риски при обновлениях, но потребует дисциплины в управлении зависимостями.
