DRY
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
Eu adoraria ouvir suas outras histórias e situações semelhantes ao que acabei de escrever neste post, você pode me encontrar em @infraascode_br ou linkedin.com/in/leonardoml/ .
Te convido a ver os outros posts do blog Infra-as-Code garanto que tem coisas legais lá!!
|
|
