Concrete Logo
Hamburger button

Introdução ao Powershell – Módulo 2: Funções

  • Blog
  • 8 de Maio de 2017
Share

Digamos que você se depara com o seguinte script:

Notoriamente há o que melhorar, certo? Vamos então listar os pontos de melhoria para guiar nosso “code refactor”:

1. Há trechos de chamadas repetidas, que podem ser transformados em funções.
2. Esse script executa SOMENTE isso, não há reutilização para nenhum dos pedaços contidos nele.
3. Há hardcoding em alguns pontos.
4. Não há um padrão claro de nomenclatura para as variáveis.

Vamos resolver por etapas?

Etapa 1: Criar funções para remover a repetição de chamadas dentro do código.

A primeira que me vem em mente é a mais simples:

Existem várias formas de escrever – corretamente – funções no Posh, basicamente gosto de dividir em 3 grupos (“simples”, “funções” e “funções avançadas”). Explico:

1. “Funções simples” são as que julgo não ter a necessidade de um emprego enorme de esforço, não queremos matar um formiga com um lança chamas, né Hanz?

2. “Funções” são trechos de código que julgo precisarem um pouco mais de cuidado, por exemplo: validar o tipo de um parâmetro antes de iniciar a execução, validar se esse parâmetro está dentro de o que eu espero; tratar possíveis erros de execução; verificar se alguma dependência está previamente carregada antes de começar a execução; etc.

3. “Funções avançadas”, além de uma estrutura do Posh, são também aquelas que eu chamo de ferramentas extremamente polidas e não passiveis de falha. Essas funções demandam um esforço e conhecimento bem maior, tanto de codificação quanto de boas práticas, e também da estrutura de funcionamento do Powershell.

Lembre-se que é importante seguir as convenções de nomenclatura que podem ser encontradas aqui: Verb-Noun

Como essa nossa megera funçãozinha só executa um sleep, vou mantê-la como algo simples e acreditar que a pessoa que a invocar sabe o que está fazendo.

Nota do diabinho sentado no ombro esquerdo do editor: sempre acredite na capacidade humana de fazer coisas boas, mas sempre tenha em mente a capacidade humana de fazer caquinha.

Temos, então:

Outro trecho que pode ser escrito numa função simples é a ação de criar o Objeto Internet Explorer. Incluí um “try/catch” aqui imaginando a possibilidade de o IE não estar habilitado no SO executor, e assim já apresento essa estrutura a vocês. Fica assim:

O último trecho nessa iteração de nosso refactor que será transformado em função é a execução do “Print Screen”. Nesse vou brincar um pouco mais com a função para mostrar algumas coisas a vocês. Ela ficou assim:

A primeira coisa que podemos reparar é o bloco de comentário no início. Na verdade não são comentários e sim epecificações desta função. Isso faz com que quem for usar essa função possa executar um Get-Help Export-PrintScreen e receber essa descrição.

Ou Get-Help Export-PrintScreen -Exeples

Repare também o bloco de validação de parâmetros. Observe que o parâmetro $sSavePath [de posição Zero] é validado como um diretório que existe e definido para $HOME como default, caso o usuário não especifique nenhum outro. O parâmetro $sFileName [de posição 1] é o único obrigatório e tem uma mensagem de ajuda, que pode ser obtida com o comando Get-Help Export-PrintScreen -Parameter sFileName.

Por fim o bloco de execução em si, que recebeu padrão na nomenclatura (seguindo as recomendações oficiais), não está mais Hard Coded e foi incluído num bloco process que é um “início” do ciclo de vida avançado de uma função Posh.

Ufa… Já fizemos bastante coisa e tem só mais um pouquinho, prometo.

O próximo passo é criar uma função para encontrar os elementos dentro do Internet Explorer. Mapeei dois comportamentos de nossas ações na página. O primeiro é preencher um valor e o segundo é clicar em um botão.

Vou aproveitar e montar uma estrutura de case/switch para exemplificar seu uso.

Observe um novo tipo de validação de parâmetro chamado Validate Set. Isso faz com que ao chamar essa função por linha de comando, um comboBox SOMENTE com essas opções seja exibido, e qualquer outro valor não será aceito.

Esse é o resultado do código:

E sua chamada pode ser feita por essa linha de comando:

Muito bem! Temos agora um script mais flexível e reutilizável. Claro, ele ainda pode ser melhorado! Vamos brincar um pouco com essas melhorias no Módulo 3, 😉 Se você tiver alguma dúvida ou tem algo a dizer, aproveite os campos abaixo.

Curte a cultura DevOps e quer fazer parte de um time ágil e multidisciplinar? Clique aqui.