Вам нравится ваш PowerShell влажный или сухой?
Очень интересно наблюдать, как за эти годы эволюционировали сценарии PowerShell. Вначале сценарии PowerShell имели тенденцию быть упрощенными по своей природе и были сосредоточены на выполнении одной повторяемой задачи. Однако со временем сценарии PowerShell часто становились все более сложными. На самом деле, я видел полноценные приложения с графическим интерфейсом, написанные на PowerShell.
Одна из причин, по которой все чаще встречаются сложные сценарии PowerShell, заключается в том, что сам PowerShell становится все более многофункциональным и функциональным с каждой выпущенной версией. Конечно, вы, вероятно, могли бы также частично объяснить это тем фактом, что PowerShell существует так долго, и многие люди освоились с написанием кода PowerShell. Как бы то ни было, одной из интересных тенденций, которые я заметил в сценариях PowerShell, является внедрение практик, традиционно предназначенных для «настоящих» сред разработки.
Одной из таких практик является использование сухих сценариев PowerShell. Сухость — это аббревиатура, расшифровывающаяся как «Не повторяйся». Он основан на идее, что сценарии никогда не должны включать избыточный код. Лучше просто закодировать все один раз, а затем повторно использовать этот код так часто, как это необходимо.
Обратной стороной этого является то, что называется «мокрым сценарием». Как вы, наверное, уже догадались, мокрый скрипт — это, по сути, просто скрипт, содержащий повторяющийся код. На мокрые сценарии обычно смотрят свысока, и термин мокрый использовался как аббревиатура для самых разных вещей, таких как «Потрать время всех» или «Нам нравится печатать».
Итак, когда дело доходит до PowerShell, что лучше: создавать «мокрые» или «сухие» сценарии?
Основываясь на том, что я уже сказал в этой статье, выбор кажется очевидным. Тем не менее, я твердо верю в то, что все имеет свое место. Хотя у написания сухих сценариев есть явные преимущества, я думаю, что можно также привести аргументы в пользу того, чтобы писать какие сценарии — по крайней мере, в особых обстоятельствах.
Тот факт, что некоторые люди утверждают, что «мокрый» расшифровывается как «Нам нравится печатать», может означать, что одно из больших преимуществ создания сухого сценария заключается в том, что он короче по длине. Однако это не обязательно так. Представьте на мгновение, что вы хотите создать сценарий PowerShell, который выводит на экран слова Hello World, а затем повторяет фразу на следующей строке (отображая текст дважды). Вот как может выглядеть сырая версия такого скрипта:
А теперь пример сухой версии того же скрипта
Влажная версия скрипта состояла из двух строк кода, а сухая версия содержала шесть строк кода. Одни только вызовы функций сухого скрипта были такими же длинными, как и весь мокрый скрипт. Дело в том, что сухие сценарии не всегда короче. В этом примере сухой сценарий был в три раза длиннее, чем мокрый сценарий.
Точно так же сухие сценарии не всегда легче отлаживать (хотя это и возможно). В конце концов, вы бы предпочли отлаживать две строки кода или шесть? Я хочу сказать, что, когда дело доходит до создания действительно коротких и простых сценариев, сухой сценарий часто бывает излишним. Между прочим, есть сухие сценарии, которые короче, чем влажные. Один тип сценария не обязательно всегда будет короче другого. Это просто зависит от того, как написан сценарий и для чего он предназначен.
Так почему же сухой сценарий лучше сырого? Настоящее преимущество использования сухого сценария заключается в том, что он дает вам последовательность. Когда вы пишете функцию, эта функция будет вести себя точно так же при каждом вызове. С другой стороны, если бы вы просто вводили набор команд каждый раз, когда они были необходимы, а не превращали эти команды в функцию, то могли бы быть незначительные изменения от одного экземпляра командного блока к другому. Однако когда вы пишете блок кода и превращаете его в функцию, вам нужно отлаживать этот код только один раз. Это реальное преимущество сухого сценария.
На мой взгляд, сухой сценарий обычно является лучшим подходом для всех сценариев, кроме самых простых. Тем не менее, я видел две ситуации, в которых сухой сценарий работал не так хорошо.
Первой из них была ситуация, в которой кто-то довел концепцию сухого сценария до крайности. Сценарий этого человека задействовал все, и я имею в виду все. Сценарий представлял собой запутанный беспорядок вложенных функций, а все тело сценария представляло собой просто длинную цепочку вызовов функций. Из-за того, как был написан сценарий (со всеми постоянными метаниями между функциями), отладка сценария оказалась монументальной работой. Большой урок, который этот человек усвоил благодаря своим усилиям по отладке, заключался в том, что если вы собираетесь писать такой скрипт, вам следует отлаживать каждую функцию по мере ее создания. В противном случае становится слишком сложно найти источник проблемы.
Второй пример сценария PowerShell, в котором сухой сценарий работал не так хорошо, — это сценарий, в котором все функции были включены в модуль, а не в тело сценария. Создание пользовательских модулей — относительно распространенная практика, и в создании модулей нет ничего плохого. Причина, по которой это было проблематично в этом случае, заключалась в том, что сценарий был передан нескольким другим людям, ни один из которых не понял, что существуют внешние зависимости.
Итак, что лучше для PowerShell: «мокрые» сценарии или «сухие»? Как правило, я склонен думать, что сухие сценарии — лучший подход для подавляющего большинства ситуаций. Тем не менее, есть такая вещь, как слишком много хорошего, и поэтому важно убедиться, что методы сухого написания сценариев не доведены до крайности до такой степени, что любые преимущества полностью сводятся на нет.