¿Te gusta tu PowerShell húmedo o seco?

Es realmente interesante ver cómo ha evolucionado el scripting de PowerShell a lo largo de los años. Inicialmente, los scripts de PowerShell eran bastante simplistas y se centraban en realizar una única tarea repetible. Sin embargo, con el tiempo, los scripts de PowerShell a menudo se volvieron más y más complejos. De hecho, he visto aplicaciones GUI completas escritas en PowerShell.

Una de las razones por las que vemos secuencias de comandos de PowerShell cada vez más sofisticadas es que el propio PowerShell se ha vuelto más poderoso con cada versión lanzada. Por supuesto, probablemente también pueda atribuir parte de esto al hecho de que PowerShell ha existido durante tanto tiempo y que muchas personas se han acostumbrado a escribir código de PowerShell. Independientemente, una de las tendencias interesantes que he visto con respecto a las secuencias de comandos de PowerShell es la adopción de prácticas tradicionalmente reservadas para entornos de desarrollo "reales".

Una de esas prácticas es la adopción de scripts secos de PowerShell. Dry es un acrónimo que significa Don't Repeat Yourself. Se basa en la idea de que los scripts nunca deben contener código redundante. Es mejor simplemente codificar todo una vez y luego reutilizar ese código tantas veces como sea necesario.

La desventaja de esto es lo que se conoce como secuencias de comandos húmedas. Como probablemente haya adivinado, el script húmedo es esencialmente solo un script que contiene código repetitivo. Los guiones húmedos generalmente se desprecian, y el término nass se ha utilizado como un acrónimo para todo tipo de cosas, como "Waste Everyone's Time" o "We Enjoy Typing".

Entonces, cuando se trata de PowerShell, ¿es mejor crear scripts húmedos o secos? Basado en lo que he dicho hasta ahora en este artículo, la elección parece obvia. Sin embargo, creo firmemente que todo tiene su lugar. Si bien hay claras ventajas en escribir guiones secos, creo que también puede haber argumentos sobre qué guiones escribir, al menos en circunstancias especiales.

El hecho de que algunas personas afirmen que Wet significa We Enjoy Typing parece implicar que una de las grandes ventajas de hacer un guión seco es que el guión es más corto. Sin embargo, eso no es necesariamente cierto. Imagine por un momento que desea crear un script de PowerShell que muestre las palabras "Hello World" en la pantalla y luego repita la oración en la siguiente línea (con el texto apareciendo dos veces). Una versión húmeda de dicho script podría verse así:

Escribir anfitrión "Hola mundo" Escribir anfitrión "Hola mundo"

Ahora aquí hay un ejemplo de una versión seca del mismo script

función hola mundo { Escribir anfitrión "Hola mundo" } Hola Mundo Hola Mundo

La versión húmeda del script constaba de dos líneas de código, mientras que la versión seca contenía seis líneas de código. Solo las llamadas a funciones del script seco eran tan largas como el script húmedo completo. El punto es que los guiones secos no siempre son más cortos. En este ejemplo, la escritura seca fue tres veces más larga que la escritura húmeda.

Del mismo modo, los scripts secos no siempre son más fáciles de depurar (aunque pueden serlo). Finalmente, ¿preferiría depurar dos o seis líneas de código? Mi punto es que los scripts secos a menudo son excesivos cuando se trata de crear scripts realmente cortos y simples. Por cierto, hay tipografías secas que son más cortas que las tipografías húmedas. Un tipo de guión no siempre tiene que ser más corto que el otro. Solo depende de cómo se escribe el guión y para qué está diseñado.

Entonces, ¿por qué una secuencia de comandos seca podría ser superior a una secuencia de comandos húmeda? El beneficio real de usar un script seco es que te da consistencia. Cuando escribes una función, esa función se comporta exactamente igual cada vez que se llama. Por otro lado, si simplemente escribiera una serie de comandos según fueran necesarios, en lugar de convertir esos comandos en una función, podría ver ligeras variaciones de una instancia del bloque de comandos a la siguiente. Sin embargo, si escribe un bloque de código y lo convierte en una función, solo necesita depurar ese código una vez. Ese es el verdadero beneficio de las secuencias de comandos secas.

En mi opinión, las secuencias de comandos secas suelen ser el mejor enfoque para todas las secuencias de comandos, excepto las más simples. Aún así, me he encontrado con dos situaciones en las que las secuencias de comandos secas no funcionaron tan bien.

El primero de ellos fue una situación en la que alguien llevó el concepto de secuencias de comandos secas al extremo. El guión de esta persona funcionalizó todo, y me refiero a todo. La secuencia de comandos era un lío enredado de funciones anidadas, y todo el cuerpo de la secuencia de comandos era solo una larga cadena de llamadas a funciones. Debido a la forma en que se escribió el script (con todo el constante ir y venir entre funciones), depurar el script resultó ser un tremendo esfuerzo. La gran lección que aprendió la persona a través de sus esfuerzos de depuración fue que si está escribiendo un script como este, debe depurar cada función a medida que la construye. De lo contrario, se vuelve demasiado difícil encontrar la causa de un problema.

El segundo ejemplo de una secuencia de comandos de PowerShell en la que las secuencias de comandos secas no funcionaron tan bien fue una en la que toda la funcionalidad estaba integrada en un módulo en lugar de incluirse en el cuerpo de la secuencia de comandos. La creación de módulos personalizados es una práctica bastante común y no hay nada de malo en crear módulos. El motivo del problema en este caso fue que el script se compartió con varias otras personas, ninguna de las cuales se dio cuenta de que había dependencias externas.

Entonces, ¿cuál es mejor para PowerShell, scripts húmedos o scripts secos? Como regla general, tiendo a pensar que las secuencias de comandos secas son el mejor enfoque para la gran mayoría de las situaciones. Aún así, existe algo demasiado bueno, por lo que es importante asegurarse de que las técnicas de secuencias de comandos secas no se lleven al punto en que se anulen por completo todos los beneficios.

¿Te gusta tu PowerShell húmedo o seco? apareció primero en TechGenix.