Рекомендации по написанию сценариев PowerShell (часть 4)

• Рекомендации по написанию сценариев PowerShell (часть 2)
• Рекомендации по написанию сценариев PowerShell (часть 3)
• Рекомендации по написанию сценариев PowerShell (часть 5)
• Рекомендации по написанию сценариев PowerShell (часть 6)

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

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

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

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

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

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

Одна из лучших практик, появившихся за последние пару лет, — называть функции PowerShell таким же образом, как и собственные командлеты PowerShell. Предположим на мгновение, что вы разрабатываете функцию PowerShell для отображения определенного отчета. Вы можете создать функцию под названием Report, но это будет немного двусмысленно. Я имею в виду, что делает функция Report? Он создает отчет? Отправляет ли отчет по электронной почте? С другой стороны, если вы создаете функцию с именем Display-Report, то мало кто сомневается в том, что делает эта конкретная функция.

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

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

Сбор данных отчета

Компиляция-Отчет

Дисплей-отчет

Поделиться-Отчет

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

Конечно, весь код должен куда-то идти. Так как же построить сами функции таким образом, чтобы скрипт оставался читабельным?

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

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

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

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

Вывод

Когда дело доходит до написания функций PowerShell, не так много единообразия в отношении установленных передовых практик. У каждого, кажется, есть свой собственный способ делать вещи. Независимо от того, решите ли вы перенять некоторые или все мои лучшие практики или решите делать что-то по-своему, ваша цель должна состоять в том, чтобы сделать ваш код максимально удобным для чтения.

В следующей статье этой серии я собираюсь еще немного поговорить о функциях PowerShell. На самом деле я только начал царапать поверхность в отношении функций, и есть больше лучших практик, которыми я хочу поделиться.

• Рекомендации по написанию сценариев PowerShell (часть 2)
• Рекомендации по написанию сценариев PowerShell (часть 3)
• Рекомендации по написанию сценариев PowerShell (часть 5)
• Рекомендации по написанию сценариев PowerShell (часть 6)