Проектирование

В данном уроке мы рассмотрим вопросы, связанные не с разработкой, а именно с проектированием под Bitrix Framework.

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

В модели проектирования должны быть отражены следующие вещи:

• права и роли (необходимо определить, кто что может делать и где);
• структура контента сайта (список страниц и разделов);
• шаблоны сайта и их динамика;
• меню сайта;
• свойства страниц и разделов, как выполняется управление ими;
• модели данных и работа с ними (инфоблоки, кастомизированные формы административной части)
• компоненты и их размещение на страницах;
• поиск на сайте;
• иногда веб-сервисы;
• выгрузка во внешние системы (при необходимости), синхронизация данных с внешними системами;
• многосайтовость (если используется).

  Что должно быть в ТЗ

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

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

При составлении технического задания обратите внимание, что публичная часть модифицируется очень гибко, а административная часть модифицируется значительно сложнее и только в ограниченных местах. В ТЗ должно быть кратко описано то, что делается с помощью стандартных возможностей (можно ссылаться на официальную документацию и учебные курсы), а весь нестандартный функционал должен быть описан детально. Если необходима разработка кастомных админок (в очень редких случаях), то по ним также составляется детальное описание.

Права и роли в ТЗ

В системе Bitrix Framework права и роли играют ключевое значение. В техническом задании необходимо расписать роли, настраиваемые группы пользователей для этих ролей. Если вам не хватает возможностей стандартных уровней доступа, вы можете добавить свои уровни доступа. Все настроенные права доступа необходимо тщательно тестировать для всех групп пользователей.

Инфоблоки в ТЗ

Как правило, все сущности и данные представляются в Bitrix Framewok инфоблоками и некоторыми объектами из модулей. Поэтому в ТЗ вам необходимо четко определить типы инфоблоков, типы полей инфоблоков. Необходимо расписать модель сущностей, указать, как инфоблоки связаны между собой. Направление связей инфоблоков очень важно с точки зрения производительности. В связи с этим модель сущностей следует обсудить с разработчиком, чтобы не было тяжелых запросов. В случае необходимости можно прибегнуть к денормализации данных.

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

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

Компоненты в ТЗ

В ТЗ следует подробно расписать, какие компоненты используются на страницах сайта. Кроме того, полезно указать, из каких инфоблоков тянет данные тот или иной компонент. Для нестандартных компонентов необходимо описать все их свойства. В параметрах компонентов не должно быть настроек, не связанных с логикой работы проекта. Если у компонента сложная логика работы (например, зависящая от настроек модуля), то об этом также необходимо отметить в ТЗ.

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

E-commerce в ТЗ

В первую очередь необходимо четко понимать, для чего нужен модуль Интернет-магазин, а для чего - Торговый каталог. Таким образом, в ТЗ должно быть указано, какие именно модули вам нужны, а также нужно ли вам много корзин.

В ТЗ обязательно должна быть подробно описана логика ценообразования, система скидок, как выполняется округление при пересчете цены. Вопросы, связанные с используемыми типами товаров (наборы, комплекты, торговыми предложениями) и остатками, также должны быть освещены в ТЗ.

Статусы заказов полезно описать с помощью диаграммы статусов (диаграммы состояний UML). Платежные системы, службы доставки и все нестандартные настройки других объектов, связанных с магазином, необходимо также добавить в ТЗ. Не следует забывать описывать и используемый формат импорта/экспорта данных магазина.

Веб-сервисы в ТЗ

Нередко в сложных проектах нужно обеспечить взаимодействие магазина, например, с SAP или с 1С, но не по стандартному протоколу обмена. В этом случае может быть удобным использование веб-сервисов, особенно если необходимо быстро передавать изменения. Механизм работы и использование веб-сервисов полезно отображать с помощью диаграмм UML: деятельности (activity), последовательности и др.