Стандарты разработки отчетов

Рвав-рвав, собака Смайл уменьшает энтропию разработок!

Сначала, как обычно, небольшое вступление. Довелось тут недавно хозяину переписывать одну большую разработку, сделанную совместно с его коллегой (Дмитрием Власовым) примерно 4 года назад, да еще, к тому же, измененную сторонними разработчиками.

Переписывалась она долго и упорно, в результате чего получились некие личные «стандарты разработки», которыми, собственно, хотелось бы с вами поделиться.

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

• Вы можете использовать Power BI Desktop в файловом варианте, ну и самое интересно, если опустить вопрос лицензионного соглашения, это не будет вам стоить абсолютно ничего.

Рвав-рвав, таких вариантов, кроме как «побаловаться», собака Смайл практически не встречал.

• Вы можете использовать гибридный вариант разработки, используя Power BI Desktop для создания мастер-датасета, а Power BI Service для создания отчетности. Это более экзотический вариант для смелых личностей, и ответственных пользователей, с примерной цепочкой следующего вида:

• К экзотике относится и вариант с использованием, например, потоков данных в качестве источника данных при разработке отчетов.

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

• Ну и напоследок, в качестве завершения этого раздела, есть так называемый «главный совет», а именно: не ленимся, читаем документацию, и следуем официальным рекомендациям. Если вы используете в своей компании Report Server, то правильно будет использовать для разработки Power BI Desktop RS, а не старую версию «обычного» Power BI Desktop.

Рвав-рвав, вы спросите: «А при чем здесь это?». Как это ни грустно, но есть довольно много случаев, когда используются старые версии обычного Power BI Desktop, поскольку отчеты, разработанные в этих версиях, можно опубликовать на Report Server. В общем, это я к тому, что обходные пути иногда выходят боком.

• После установки MS Power BI Desktop первое, что надо сделать — это определиться с тем, а какая, собственно, локаль вам необходима: оригинальная (английская), русская (или иной вариант). Локаль считывается с настроек в Windows при создании файла, и в дальнейшем не меняется. При этом следует иметь в виду, что локаль в облачной службе в Power BI Service у вас может быть отличной от локали, используемой в Power BI Desktop.

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

• Далее необходимо, на мой взгляд, зайти в настройки созданного файла, и вдумчиво поработать над всем многообразием используемого функционала с учетом следующих принципов: все, что не нужно, должно быть или отключено, или изменено. В качестве примера параметра для отключения можно привести «Автоматическую иерархию дат», которая является довольно-таки вредной штукой:

• Или, если вы используете кастомные коннекторы, необходимо дать программе разрешение на работу любого расширения (а им и является кастомный коннектор) без дополнительных проверок:

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

• Если вдруг ваш клиент изъявил желание, в том числе, иметь кастомную тему, то лучше сделать ее именно на первоначальном этапе, поскольку вопрос не только в цветах и возможном «перекрашивании» готового результата, но также и в применении кастомного шрифта, так как с этим в Power BI довольно-таки бедно.

• Запросы к источникам данным желательно структурировать, благо такая возможность появилась достаточно давно:

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

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

• Можно осуществить форматирование исходного кода, например, при помощи бесплатного инструмента, доступного по ссылке: PQ Formatter

• Если Power BI используется в режиме импорта данных, нужно стараться импортировать только то, что необходимо, а не действовать по принципу: «Возьму все, потом вдруг пригодится».

• Ну и напоследок: при работе с некоторыми источниками (например, MS SQL), используется так называемый фолдинг. При трансформации данных необходимо периодически проверять, а не сломали ли вы в процессе разработки данную процедуру, поскольку даже в неоптимизированном «машинном» виде это сильно влияет на быстродействие всей системы в целом.

• Здесь, поскольку все очень разнообразно, придется ограничиться всего несколькими рекомендациями. Например, код расчетных столбцов и мер также желательно форматировать при помощи следующего инструмента: DAX Formatter

• Структурировать данные можно при помощи соответствующих каталогов:

• Меры, используемые в модели, также можно сложить в отдельную таблицу, и, при желании, использовать каталоги:

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

• При осуществлении расчетов необходимо стремиться использовать меры, а не расчетные столбцы.

• Желательно оставлять комментарии в коде, особенно, если у вас несколько разработчиков.

• Константы в формулах используем только там, где есть уверенность, что ничего не изменится.

• При написании формул лучше использовать «правильные» функции, например, использовать функцию «SWITCH» вместо нескольких вложенных функций «IF», если у вас несколько условий.

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

• При построении визуальных элементов, особенно, если у вас длинные названия столбцов, можно попытаться их сократить, используя псевдонимы.

Рвав-рвав, по поводу дизайна что-то советовать неблагодарное дело, поскольку ««а вкус и цвет все фломастеры разные», но лично я при разработке отчетов пользуюсь специальными сервисами для подбора цветов, не гнушаюсь символов UNICODE, всяческих фигурок и прочее…

• И последнее, из общих советов — это, собственно, дублирование разработок. Делаем копии отчетов, и, желательно, храним не только локально, но и где-нибудь в облаке.

Рвав-рвав, собака Смайл знает, о чем глаголет, поскольку недавно мы с хозяином заимели большие проблемы с HDD. Много всего пропало, до сих пор не оправились… Но мы продолжаем борьбу!

Ваш Смайл