Post-Image

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

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

Сначала, как обычно, небольшое вступление. Довелось тут недавно хозяину переписывать одну большую разработку, сделанную совместно с его коллегой Дмитрием Власовым примерно 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.

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

    Месяц на английском языке = 
    FORMAT ( 'Таблица'[Дата календаря], "MMMM", "en-us" )

    art_019_screen_01

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

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

    В качестве примера параметра для отключения можно привести «Автоматическую иерархию дат», которая является довольно-таки вредной штукой:

    art_019_screen_02

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

    art_019_screen_03

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

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

    УРОВЕНЬ POWER QUERY

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

    art_019_screen_04

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

    art_019_screen_05

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

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

    Форматирование кода Power Query

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

    УРОВЕНЬ МОДЕЛИ (DAX)

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

    Форматирование кода DAX

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

    art_019_screen_06

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

    art_019_screen_07

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

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

    ОБЩИЕ МОМЕНТЫ

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

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

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

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

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

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

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

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

    Ваш Смайл