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

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

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

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

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

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

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

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

Конечно, иногда не только опытные ИТ-специалисты получают доступ к моему коду PowerShell. Большая часть кода, который я пишу, отправляется в Интернет в образовательных целях. Обычно этот код находится в теле статьи, и такая статья, очевидно, объясняет, как работает код. Однако иногда я делал сценарии PowerShell доступными для загрузки. Когда я создаю такой сценарий, мое эмпирическое правило заключается в том, что я документирую сценарий так, как будто пытаюсь объяснить его своей маме (которая, вероятно, никогда даже не слышала о PowerShell). Дело в том, что я провожу столько ручных операций, сколько могу, не делая сценарий настолько тяжелым комментариями, чтобы фактический код терялся в море комментариев.

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

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

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

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

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

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

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

Вывод

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

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