Методика разработки 1C Конфигураций

Проектирование 1С Конфигураций

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

Уже на этом этапе начинаются серьезные отличия. При создании простых прикладных решений собственно процесс проектирования может зачастую вообще отсутствовать. Это связано с тем, что структура объектов метаданных позволяет разработчику мыслить не таблицами и полями, а объектами, описывающими сущности конкретной прикладной области. Поэтому зачастую термины предметной области однозначно и полностью могут быть перенесены в структуру метаданных. Например, если заказчик использует каталог товаров и два документа, которые регистрируют поступление и расход товаров, то ровно таким же образом эта структура может быть перенесена и в прикладное решение: один справочник и два документа. Если требуемая функциональность решения невелика, то разработчик вполне может держать структуру метаданных в голове, и запись на бумаге может потребоваться лишь для отражения в документации.

Совершенно другая картина возникает, когда начинается разработка крупного проекта. Здесь уже требуются усилия нескольких человек, как для постановки задачи, так и для проектирования. Причем в процессе проектирования приходится решать ряд дополнительных задач.

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

Если бы важность правильного выбора объектов метаданных была бы обусловлена только этой причиной, одно это явилось бы достаточно серьезным поводом, чтобы уделить процессу проектирования значительное внимание. Однако есть еще целый ряд факторов, которые еще больше поднимают значимость этапа проектирования.

Если в простой конфигурации при проектировании и метаданных будет допущена ошибка, то это, конечно, неприятный факт, но не катастрофический. При определенных условиях даже полная переделка всего прикладного решения может быть выполнена в разумные сроки и разумными средствами. Однако если ошибка в проектировании метаданных будет допущена в крупном проекте, это может стать полной катастрофой, поскольку потребует огромных ресурсов для ее исправления и «встраивания» новых объектов и новых алгоритмов в уже существующее прикладное решение.

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

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