Reflexiones sobre los juegos de secuencias de comandos de PowerShell
Permítanme también dejar claro, para aquellos de ustedes que aún son nuevos en PowerShell, que cuando lo usan de forma interactiva en un indicador de PowerShell, todo vale si les ayuda a realizar el trabajo de manera eficiente. Pero cuando se crea una solución PowerShell con script, algo que perdurará, las pautas son un poco diferentes.
Es cierto que los desafíos de esta última serie de juegos fueron complejos. Francamente, no estoy seguro de cómo habría empezado con algunos de ellos. Dicho esto, al final todavía estamos hablando de scripts de PowerShell. Una cosa que me llamó la atención en las entradas que juzgué fue la frecuencia con la que sentí que estaba leyendo el código fuente de un proyecto de Visual Studio y no un script de PowerShell. Por un lado, eso podría considerarse algo bueno: PowerShell es lo suficientemente flexible como para crear cualquier cosa, desde scripts básicos hasta los tipos de entradas que revisé. Pero, de nuevo, si tienes las habilidades técnicas para crear un código como el que leí, probablemente puedas crear un conjunto "real" de herramientas compiladas. En algún momento de su proceso de desarrollo, es posible que se pregunte si está creando un script de PowerShell o si ha ido más allá y tal vez un script no sea la solución adecuada. Sí, las entradas del juego debían ser módulos y scripts de PowerShell, pero ¿qué pasa con lo que estás trabajando?
Aun así, esto me lleva al siguiente punto: la mantenibilidad. La mejor manera de probar esto es entregar sus archivos de script a otra persona, idealmente con un poco menos de conocimiento de PowerShell que usted, y ver si puede entender qué hacen sus scripts y cómo. Muchas de las entradas que leí eran masas extensas y complicadas de funciones, scripts y código .NET. En muchos casos me desafiaron a intentar descubrir qué estaba pasando. Si *yo* tengo que esforzarme para descubrir cómo funcionan todas las piezas de su script o módulo, piense en su compañero de trabajo a quien le entregan su solución para que la mantenga o solucione el problema cuando lo ascienden. O podría ser que vuelvas a hacerlo en 6 meses.
No hay penalización por comentarios. Animo a los principiantes a escribir los comentarios primero para que puedan organizar y planificar su trabajo. Para un módulo, también puedes escribir tus propios temas de ayuda Acerca de. En mi opinión, información como esta es tan importante como los comandos de PowerShell que estás utilizando.
Por último, tengo las preocupaciones habituales sobre la sintaxis y la elección del idioma. Sí, sé que siempre hay excepciones. No recurra al uso de clases .NET cuando un cmdlet sea suficiente. Utilice verbos estándar y sustantivos significativos en los nombres de sus comandos. Pero quizás lo que más me molesta es el uso continuo de la palabra clave Return.
Cada vez que veo la palabra clave Return, siento que el autor del script no ha comprendido completamente el paradigma de PowerShell. En mi opinión, no devolvemos valores, escribimos objetos en la canalización. La única vez que uso Return es cuando intencionalmente quiero salir de un script o función y terminar todo con gracia. Por lo general, cuando veo el uso de Return, también veo muchas funciones auxiliares innecesarias, cada una de las cuales tiene como objetivo "devolver" algo. Esto sólo aumenta la complejidad (innecesaria) de su trabajo. Agregue la falta de documentación y tendrá un lío de PowerShell, llamémoslo, subóptimo.
Un archivo de script de PowerShell bien diseñado puede ser algo hermoso.
Se abre el proceso,
los objetos florecen enviando alegría
formateado como felicidad
¿Qué opinas? ¿Qué has visto en tu empresa o en la naturaleza que sea bueno, malo o feo?