Você conhece o princípio DRY? Não?! Vai conhecer agora, imagine a seguinte situação: Numa manhã de quinta feira qualquer, você vai começar a trabalhar no seu lugarzinho preferido da casa, o dito “home offizinho” e, ….

Situação 1

Sentou, ligou o laptop, ajustou a altura da cadeira, ajustou a altura do monitor, esticou os braços e os dedos, beleza, está pronto para começar. Lembrou que esqueceu de fazer um café, levantou, foi lá, fez o café e voltou. Sentou novamente, está pronto para começar. Lembrou que esqueceu de pegar a aǵua, levantou, foi lá, pegou uma garrafa de água e voltou. Sentou novamente, está pronto para começar. Lembrou que precisa avisar na portaria que existe um vazamento na garagem, levantou pegou o interfone e avisou na portaria e voltou. Sentou novamente, está pronto para começar. Deu vontade de ir ao banheiro, claro!! Depois do café e da água era óbvio!!! 🙂 Levantou resolveu as pendências biológicas e voltou, agora sim, está pronto para começar!!!

Situação 2

Avisou na portaria que existe um vazamento na garagem. Foi ao banheiro, fez um café, trouxe a água, sentou, ligou o laptop, ajustou a altura da cadeira e do monitor, esticou os braços e dedos, beleza, está pronto para começar!!!

Percebeu alguma diferença entre as duas historinhas? Tenho certeza que sim, e qual é a diferença? O que você percebeu é o princípio DRY, que significa Don’t Repeat Yourself, em uma tradução livre seria “Não se repita", este é um conceito do livro The Pragmatic Programmer.

DRY

O princípio DRY é um conceito de desenvolvimento de software que tem como objetivo reduzir repetições. Ao seguir o princípio DRY, você precisará olhar para o seu código como se cada trecho de código fosse parte de um processo, e dessa forma buscar evitar e remover redundâncias nos processos. Para ter esse olhar, é preciso fazer o uso de alguns elementos de programação que criam abstrações tipo: Classes, funções, segregação de responsabilidade do código.

Vejamos um exemplo prático com um código de Ansible para criar alguns arquivos, num determinado caminho e configurar algumas permissões e propriedade de dono e grupo.

 1- name: Change file ownership, group and permissions
 2  file:
 3    path: /etc/laptop.conf
 4    owner: laptop
 5    group: laptop
 6    mode: '0644'
 7
 8- name: Change file ownership, group and permissions
 9  file:
10    path: /etc/cafe.conf
11    owner: cafe
12    group: cafe
13    mode: '0644'
14
15- name: Change file ownership, group and permissions
16  builtin.file:
17    path: /etc/agua.conf
18    owner: agua
19    group: agua
20    mode: '0644'
21
22- name: Change file ownership, group and permissions
23  file:
24    path: /etc/portaria.conf
25    owner: portaria
26    group: portaria
27    mode: '0644'
28
29- name: Change file ownership, group and permissions
30  file:
31    path: /etc/banheiro.conf
32    owner: banheiro
33    group: banheiro
34    mode: '0644'

Veja agora como como fica aplicando o método DRY nesse mesmo trecho de código

 1- name: Change file ownership, group and permissions
 2  file:
 3    path: {{ item.path }}
 4    owner: {{ item.owner }}
 5    group: {{ item.group }}
 6    mode: '0644'
 7  with_items:
 8    - { path: '/etc/laptop.conf', owner: 'laptop'  , group: 'laptop' }
 9    - { path: '/etc/cafe.conf', owner: 'cafe' , group: 'cafe' }
10    - { path: '/etc/agua.conf', owner: 'agua' , group: 'agua' }
11    - { path: '/etc/portaria.conf', owner: 'portaria' , group: 'portaria' }
12    - { path: '/etc/banheiro.conf', owner: 'banheiro' , group: 'banheiro' }

Percebeu alguma diferença entre os dois trechos de código? Tenho certeza que sim, o que você percebeu é o princípio DRY sendo aplicado em um script de automação. Os dois trechos de código fazem e-x-a-t-a-m-e-n-t-e a mesma coisa, mas um possui 34 linhas e o outro tem 12 linhas. Agora, me diz aeee, qual deles você se sentiria mais confortável em dar manutenção? Lindo isso, não?!? 😍 😍

Conclusão

O objetivo do princípio DRY é melhorar a manutenibilidade do código. Seguir esse modelo vai ter ajudar alterar o código em um só lugar e ter a alteração aplicada automaticamente a todas as instâncias do seu projeto. Isso é uma vantagem enorme!!!

Para ser capaz de utilizar isso no Ansible, por exemplo, é preciso conhecer as possibilidades das estruturas de dados para armazenar variáveis simples e complexas. Conhecer o funcionamento das interações entre roles, tasks, playbooks, precedências e escopo de variáveis, esses conhecimentos vão dar possibilidades de fazer coisas bem legais!

Referências

• Livro The Pragmatic Programmer
• https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_variables.html#:~:text=In%20general%2C%20Ansible%20gives%20precedence,that%20variable%20in%20the%20namespace.
• https://ansible-docs.readthedocs.io/zh/stable-2.0/rst/playbooks_loops.html
• https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_loops.html

MENTORIA

Curtiu o blog? Quer trocar uma ideia comigo sobre algum post?

Marca Aqui! É um papo gratuito oferecido para quem é leitor do blog, podemos falar de temas como: DevOps, SRE e carreira em TI.

Te convido a ver os outros posts do blog Infra-as-Code garanto que tem coisas legais lá!!

--- --- IMPORTANTE --- --- As opiniões aqui expressas são pessoais e de responsabilidade única e exclusiva do autor, elas não refletem necessariamente a posição das empresas que eu trabalho(ei) e/ou presto(ei) serviço.