Заказ дилера: обновления апрель-май 2015

За последние 2 месяца в функционале Заказа дилера не появилось заметных пользователям изменений.
Чем же занят разработчик? Почему игнорирует задачи в redmine и не отвечает на письма?

Фреймворк или программа?

Фреймворк (framework) — платформа, определяющая структуру программной системы.
Во времена, когда вся УПзП жила внутри 1С, такого вопроса не возникало. Есть платформа, есть метаданные и язык 1С. Разработчик может спокойно писать код, не заморачиваясь вопросами эффективности и прозрачности транспорта данных

На корпоративном рынке много программ, реализованных без строгих фреймворков. Ограничения на интерфейс, форматы сообщений и структуры данных, накладывает разработчик прикладного решения, что порождает некоторые проблемы:

• В очередных версиях эти ограничения меняются и мы наблюдаем разный стиль в формах, разный синтаксис вызова методов и разные форматы сообщений обмена
• Об интеграции со сторонними системами, речь как правило не идёт. В лучшем случае, документируются поля таблиц SQL
• Из-за отсутствия внятной структуры, программа быстро достигает порога сложности, затрудняющего дальнейшее развитие
• Разобраться в алгоритмах, вести изменения или реализовать новый функционал, как правило, под силу только самим разработчикам, но и для них это сложная задача

Проект Заказ дилера стартовал в 2014 году не от хорошей жизни.
При всех достоинствах и возможностях платформы 1С, имелись ограничения:

• Высокая стоимость рабочего места (от 10 тыс. руб)
• Низкое быстродействие на медленных интернет-каналах
• Отсутствие инструментов для работы с векторной графикой

Подробнее про постановку задачи см. презентации зачем это надо, как это сделано, а так же, документацию по API
На старте мегапроекта Заказ дилера, я отлично понимал, что ввязываюсь сразу минимум в три, а то и 5 проектов: Синхронизация с 1С, интерфейс веб-приложения, графический построитель, автономное рабочее место и мн. другое. Части веб-сервиса предполагалось с одной стороны, тщательно изолировать, с другой - даже пользователь с микроскопом не должен увидеть швов в собранной системе.

Готовой среды разработки с поддержкой метаданных и прозрачной синхронизации с сервером найти не удалось. Рассматривались как модные веб-фреймворки (ExtJS, Qooxdoo, MeteorJS, YUI, Dojo и т.д.), так и наборы компонентов для настольных компиляторов Embarcadero и Visual Studio
Возможно, я плохо искал и готовая среда разработки веб-приложений существует. Возможно, я избалован высокоуровневой объектной моделью 1С, но есть подозрение, что искал я нормально, за дешевизной не гнался, но нужные функции есть только во фреймворках "больших" ERP систем. Решение на основе MS Dynamics или SAP R3 вряд ли получилось бы шустрее и дешевле 1С, а это - два основных требования к системе.

Приоритеты

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

• Тираж
• Внедрения чужими руками

Эти цели однозначно определили приоритеты разработки:

• Проект должен быть с открытым кодом
• Открытый код совсем не означает бесплатности, открытый код не гарантирует качества, но обратное можно принять как аксиому: закрытый код почти всегда низкого качества
• Упрощать код и алгоритмы до тривиальности
• Части программы должны быть подобны бутылям или цистернам огромной ёмкости, но с очень узкими горлышками. Внутренняя сложность объектов должна быть скрыта простыми программными интерфейсами
• Оформление кода в соответствии с рекомендациями сообщества
• Минимизация контекста при вызовах методов
• Встроенные инструменты сериализации, выгрузки и загрузки любого объекта данных
• Подробная и актуальная документация

С последними двумя пунктами уже сейчас всё хорошо:

• Фреймворк metadata.js (Oknosoft data engine) - первый в моей жизни проект, в котором документация рождается раньше кода. Она не является аппендиксом, отравляющим жизнь разработчика, но помогает структурировать классы и методы и принимать инженерные решения
• Все без исключения объекты данных умеют выгружать себя + связанные объекты + метаданные в файл или на сервер. Это гарантирует простую, понятную сисадминам, а значит - надёжную интеграцию с другим ПО

Достижения

В прошедшие месяцы получены заметные результаты по приоритетным задачам:

• Улучшена структура кода, для сборки модулей задействован пакет LMD
• Работающий только в Chrome и Safari WebSQL, помеченный в W3C, как deprecated, заменён пакетом alaSQL
• Удалось избавиться от дублирования данных внутри JavaScript и хранилищем SQL. Объекты данных metadata.js объединены с таблицами alaSQL
• Функции обратного вызова асинхронных операций заменены Промисами
• Из объектной модели выброшен класс RefField. Его функции принял на себя DataObject, что обеспечило экономию памяти и позволило писать более компактный код

Говорить о качестве среды разработки можно только после реализации значительного количества проектов.
На сегодня, с использованием metadata.js существует один проект в промышленной эксплуатации (Безбумажное производство) и один проект на этапе бета-тестирования (Заказ дилера).

Возможности metadata.js для безбумажки явно избыточны. Динамические списки, отчеты, картинки на лету, сканирование и регистрацию событий можно было реализовать более простыми средствами, но фреймворк позволил минимизировать клиентский код (всего несколько сотен строчек), сделать простым и понятным

В Заказе дилера, пока реализована лишь часть функционала, но с уверенностью можно сказать, что фреймворк НЕ является узким местом.
Напротив, такие его возможности, как динамические формы объектов и списков, синхронизация по разным протоколам, клиентский SQL, клиентские и серверные события при чтении-записи объектов, автоприведение типов данных и самоконтроль объектов, делают разработку на metadata.js приятной и эффективной.