Рефакторинг в BI-проектах: когда и зачем переписывать «рабочий» код

info@vsetut.pro

Стать автором

Вернуться

10.04.2025 13:44:05 | Хабр

Хабы: Блог компании Luxms BI, Big Data, Визуализация данных, Анализ и проектирование систем

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

Начнём с простого и наболевшего. Когда создаётся первая версия дэшборда, задача звучит просто: «показать данные хоть как-нибудь и побыстрее». Не до архитектуры, не до производительности — главное, чтобы цифры появились, и руководство смогло принять правильное управленческое решение. Потом уточняется задача, добавляются новые требования, меняются источники, добавляются разрезы данных, растёт нагрузка. И вот тот самый дэшборд, собранный на скорую руку, оказывается в проде — и технически работает не так и не с той скоростью, как нужно. А далее необходимо развивать функционал, обновлять версию. И сложности растут.

В этой статье команда авторов ГК Luxms, вендора платформы бизнес-аналитики Luxms BI, расскажет, почему так происходит и почему «оптимизация» — это не про критику, а про работу с реальностью, со сложной реальностью мира IT и мира данных. А еще — почему важно не только чинить, но и уважать чужой код.

Подробнее