Система для управления производством: кейс разработки на Python

Наш разработчик временно присоединился к команде российской ИТ компании, разработчику сайтов и приложений, интегратору digital-решений. Конечный заказчик — крупный производитель продуктов питания, хорошо известный на рынке.

Проект: система для планирования производства, распределения продукции на складах и управления поставками.

Стек бэкенд: Django (высокоуровневый веб-фреймворк на Python).

Команда: четыре бэкэндера, два фронтендера, два тестировщика, два-три аналитика.

Как приходили задачи: команда разработчиков получила спецификацию для совместного изучения. После этого руководитель начал ставить конкретные задачи по этой спецификации.

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

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

Команда разработчиков получила доступ к таблицам Excel, в которых содержатся типы самых разных данных. Данные делились на несколько уровней: прогноз, расчетные данные, фактические данные. Нужно было спроектировать структуру базы данных так, чтобы с ними можно было работать, а также продумать, как хранить и копировать эти данные, оптимизировать скорость и эффективность ее работы.

Команда разработчиков под руководством тимлида спроектировала схему базы данных, а затем создала модели для всех типов данных, указанных в спецификации. Модель в Django — это класс, на основе которого создается таблица в базе данных.

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

В процессе работы параллельно создавали модели Django, Vue-модели, API и так далее. Команда использовала сериализаторы, которые позволяют преобразовывать сложные данные в удобный для хранения формат, и десериализаторы. С их помощью входные данные из таблиц Excel преобразовывались в данные для хранения в базе и наоборот.

Другая задача — валидация (проверка) данных. На проекте была сложная многоуровневая нейросистема валидации.

Команда разработала интерфейс для взаимодействия с API, который позволил загружать исходные данные в подходящем виде для планирования. Помимо загрузки использовался механизм автоматического получения исходных данных из других компонентов системы, например, от модуля ИИ.

Также был создан API, который позволял отображать загруженные данные и результаты вычислений в виде графиков. Например, таким образом можно составлять графики поставки товаров, процент загрузки автомобиля, заполняемость складов и так далее.

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