Categories
Agile

Louco por automatização!

Ultimamente tenho feito uma brincadeira que todos ficam achando que eu sou maluco. Costumo dizer que o meu objetivo a cada dia é tentar fazer com que todo o trabalho que eu faria em 2 dias seja feito em apenas 1 hora, e assim eu posso aproveitar as outras 15 horas escrevendo posts no meu blog, estudando coisas novas, jogando Guitar Hero ou até mesmo dormindo (se eu não tivesse insônia).

Parece loucura mas não é. Quando eu ainda era um jovem Padawan um dos vários mentores que tive ao longo da minha vida me ensinou uma lição muito valiosa.

Há bastante tempo atrás, observando um amigo trabalhar percebi que ele passava horas e horas automatizando cada pequena tarefa que faziamos na empresa. Se precisavamos criar uma entrada no DNS, tinha um shell script para fazer isso. Se precisavamos fazer backup, existia um script para fazer isso e ele até já funcionava sozinho. E no caso dele, ele tinha scripts prontos até para facilitar fazer as compras do mês no Zona Sul online (isso é sério mesmo). Basicamente ele era obcecado por automatizar tarefas.

Como ele passava a grande maioria do tempo automatizando coisas, um dia eu resolvi perguntar porque ele perdia tanto tempo fazendo aquilo. Não era apenas uma obsessão sem sentido, tinha um fundamento muito simples. Ele disse: “Quanto mais você trabalhar para tornar a sua vida mais fácil automatizando as tarefas repetitivas, mais você terá tempo livre para fazer mais coisas que você quiser! Fazendo assim você vai ter tempo de sobra para investir nas tarefas realmente desafiadoras, que vão exigir toda sua intelectualidade e que vão te dar prazer. É por isso que eu sempre trabalho com a meta mental de reduzir todo o trabalho que eu faria em 2 dias para 1 hora, e fazendo assim todo o dia e a todo momento as coisas simplesmente vão acontecer; e eu vou produzir muito mais que qualquer um sem absolutamente nenhum esforço”.

Eu sempre achei isso genial! Obviamente ele não passava 15 horas de bobeira fazendo outras coisas. O objetivo era apenas estabelecer uma meta agressiva de automatização de tarefas para conseguir alcançar um nível onde muitas coisas podem ser feitas com pouquissimo esforço, e a brincadeira de “passar 15 horas de bobeira” serve apenas para ilustrar e tornar o exemplo mais divertido. 🙂

Desde essa época eu venho usando essa abordagem para o máximo de coisas que eu consigo. Meu problema sempre foi que eu nunca tentei de verdade ser tão extremo quanto ele (ao ponto de automatizar até as compras do mês), mas de uns meses pra cá eu tenho sido cada vez mais e mais radical e tenho me tornado cada vez mais produtivo (apesar de ainda ir fisicamente no mercado fazer compras).

“Radical” e “extremo” são palavras que têm uma conotação muito negativa, mas ser radical ou extremo pode ser muito útil quando se tem um propósito como esse (ou então para se fazer uma abordagem como a que eu postei sobre porque eu não gosto de escrever comentários no código).

Em projetos de desenvolvimento de software, os ganhos com uma abordagem desse tipo são impressionantes. No último projeto que comecei (e que estou atualmente) propús para os meu amigos do time que tentassemos fazer uma abordagem desse tipo – radical e extrema – em relação a automatização. A regra que criamos juntos e concordamos ficou bem simples: se alguma coisa precisou ser feita mais de uma vez então ela necessariamente deve ser automatizada.

Depois de aproximadamente 3 semanas de trabalho as coisas funcionam mais ou menos assim:

  • Todos os testes unitários e de aceitação são automatizados e podem ser rodados com apenas um comando (desde criar/atualizar banco de dados até subir Selenium Server, colocar o sistema em um estado conhecido, executar os testes e depois desfazer isso tudo).
  • Toda vez que é feito um push para o Git, o build server roda primeiro todos os testes unitários automaticamente.
  • Se qualquer um dos testes falha, uma sirene toca automaticamente alertando que alguém fez besteira.
  • Se os testes passam, o Capistrano faz um deploy em cada uma das máquinas do ambiente de testes de aceitação e dispara a execução de todos os testes de aceitação nesse ambiente.
  • Se o banco de dados mudou, o upgrade do schema de banco de dados também é feito automaticamente.
  • Finalmente, quando todos os testes passam, é feito um deploy automatico para o ambiente “live”, que tem por objetivo ser o lugar onde se pode ver a última versão de desenvolvimento que passa em todos os testes.
  • Se precisarmos colocar a aplicação em produção, um script fará isso da forma mais simples, segura e instantânea possível.
  • Se um desenvolvedor precisar desenvolver nesse projeto, basta baixar o código do repositório e com um script tudo se configura e funciona automaticamente.
  • Se for preciso criar uma nova tela de cadastro padrão desse sistema, basta rodar um script e ela será quase toda criada automaticamente (apenas as particularidades precisam ser configuradas).
  • … e por aí vai.

Todas essas coisas juntas não foram simples de serem feitas, muito pelo contrário, foi bastante trabalhoso (e até chato algumas vezes). Porém, o resultado não deixa dúvidas: o ganho de performance é absurdamente alto e vale a pena cada minuto gasto investido.

No início levamos muito tempo automatizando tudo mas depois dos primeiros 3 ou 4 dias qualquer coisa passou a levar bem menos tempo do que levaria. Em pouquissimo tempo (algo em torno de 3 semanas, como eu disse) já é possível perceber resultados concretos dessa abordagem. Apesar de ainda termos um monte de coisas para melhorar, nossa agilidade para fazer coisas simples e vê-las funcionando é muito grande!

Não gaste seu nobre tempo fazendo coisas repetidas e chatas. Automatize tudo que puder! Faça os scripts trabalharem pra você!!!

44 replies on “Louco por automatização!”

Perfeito!
Lembra de uma frase do grande Leibnitz (1646-1716):
“É desonroso para os homens sábios desperdiçarem seu tempo como escravos no trabalho de cálculo, que poderia ser relegado, com segurança, a qualquer um que usasse uma máquina.”
Naquele tempo o matemático já usava ant e shell 🙂

Tambem sou adepto da automatização há alguns anos e os benefícios são realmente notáveis. Creio que este perfil é comum para todas pessoas que gostam de coisas organizadas. Belo post Guilherme.

Incrivel como ainda ontem eu criei um script que gera uma entrega do meu código para o QA da empresa, coisa extremamente simples, mas que acabava por me tomar no mínimo 1 hora para fazê-lo, como estou em fase terminal do projeto, tem ocorrido no mínimo 2 x na semana, por isso automatizei esse processo, mais incrivel ainda como o meu amigo ao lado disse que isso era besteira… e hoje esse post, perfeito, ja passei pra ele ler!

Tenho dedicado algumas horas do meu expediente pra “relaxar” exatamente fazendo isso: automatizando código repetitivo. Tem muito código por aqui sendo reescrito desnecessariamente. Pior: coisas simples de se fazer.

Me acostumei a usar frameworks. Como aqui as coisas funcionam boa parte “à moda antiga”, estou tendo que fazer este esforço.

Assisti à tua palestra no Encontro de TI. Gostei bastante.

Abraços!

“…No início levamos muito tempo automatizando tudo…” conheço bem isso; quando há tempo de automatizar as tarefas, é ótimo.
Mas, muitas vezes, o prazo já vem estourado mesmo antes do job iniciar a ser produzido :-/

[]s!

@Chris

Você é o especialista em programação do seu time ou não é? Se você é, é você quem determina como o trabalho precisa ser feito!

Por mais que eu tente eu NUNCA conseguiria convencer um médico de fazer um transplante de coração em 30 minutos, simplesmente porque não dá, esse tempo não será adequado para ele. Porque diabos então há uma facilidade enorme para convencer e obrigar programadores a fazer coisas num tempo que se sabe que é impossível?

Se você aceita esses prazos infernais e ainda faz um monte de cagadas pra conseguir entregar, a culpa é toda sua 🙂 E pior ainda, o seu chefe ainda vai te dar esporro porque você fez as besteiras.

Diminua o escopo, aumente o prazo, faça qualquer coisa, mas na qualidade do seu trabalho é VOCÊ que manda!

Também tenho mania de automatizar coisas. Tenho um script pra checar novas convocações de um concurso que fiz, e um outro pra limpar o Eclipse 3.4 depois de perceber que ele estava comendo 1GB do meu HD!

ótimo post, confesso que as vezes prefiro ir pelo caminho que “parece” ser mais rapido e evito criar scripts, mas sempre fico com raiva de mim mesmo 😉
essa estrategia de ser radical com certeza ajuda e muito !! vou passar a adotá-la =)

Guilherme, no mundo perfeito é assim que eu gostaria que funcionasse.
Mas, muitas vezes, é impossível ser tão “strict” assim – mesmo esse sendo o certo.

Por isso que quando só depende de mim, ou seja, estou fazendo um freela, posso estabelecer 100% das regras. Numa empresa, a autonomia nunca é 100% e outros fatores acabam influenciando, como, por exemplo, ter que entregar um projeto com prazo muito curto por ser estratégico. Mesmo você avisando que não tem condições de fazer com a mesma qualidade que teria com um prazo maior ou escopo menor…

[]s!

Se eu te contasse as coisas que eu e outros aqui na empresa já conseguimos fazer você não acreditaria. E no meu caso eu trabalho numa empresa gigante, extremamente tradicional e que provavelmente tem/tinha tudo que a sua tem. Inclusive eu também já sofri com esses problemas de prazos, mas felizmente eu (não fiz nada sozinho, obviamente) consegui mudar isso, inclusive para projetos muito muito estratégicos e vitais para a empresa.

Por isso tudo eu posso afirmar novamente com muita convicção: só depende de você mudar isso! 🙂

Muito bom Guilherme. Parabéns pelo Post.
Como o Diogo disse, devemos trabalhar de forma inteligente!
O que vale não é o quanto você se esforça, mas o quanto você agrega de valor. Através da automação podemos ampliar o valor que agregamos com o nosso trabalho. Sem dúvida.

Abraço.

@Alvaro

É verdade, muito bem observado. MDA é um problema. Queremos automatizar tarefas e facilitar a vida e não espalhar código duplicado e boilerplates por todo o projeto 🙂

No meu post, como deu para reparar, todos os exemplos são de tarefas de infraestrutura. São coisas que não tem nada a ver com as funcionalidades do software mas sim são pequenas automatizações para aumentar a velocidade ao fazer tarefas repetidas. A automatização de tarefas desse tipo (build, deploy, execução de testes, etc) é extremamente útil e extremamente relevante para que se tenha agilidade ao desenvolver e que não se perca tempo fazendo tarefas repetidas.

Já em relação à código de negócio, a abordagem necessariamente deve ser diferente. Ao invés de criar pequenos scripts, a preocupação maior é tentar usar os recursos da linguagem para fazer com que não seja necessário repetir duzentas vezes a mesma regra de negócio ao longo das camadas do software. Isso vira um inferno quando acontece porque para fazer qualquer alteração no software é necessário mexer em um monte de camadas para fazer qualquer coisinha simples – gerando um trabalho absurdo para o programador.

Em relação a ferramentas de MDA, o problema é que elas muitas vezes são baseadas em geração massiva de código, ignorando a arquitetura do software, gerando código duplicado e difícil de manter. Esse é o tipo de software que terá manutenabilidade comprometida ao longo do tempo.

Muito mais inteligente é trabalhar como o Django faz, por exemplo. Dado que você cria um objeto Model, o Django se encarrega de criar uma porção de telas para CRUD que refletem aquele modelo, validação de formulários de acordo com os tipos de dados (string, integer, etc), controlers e até colunas no banco de dados, tudo automaticamente mas sem duplicação de código. A definição do modelo está em apenas um lugar e todas as telas, controllers e o banco de dados são gerados conforme essa definição, evitando que haja duplicação de definições.

Outro bom exemplo é uma aplicação Rails. Depois que você define o modelo da aplicação em apenas um lugar (nas migrations), todo o Model da aplicação é automaticamente gerado sem que haja necessidade de escrever a definição em mais de um lugar. Não é necessário duplicar as definições que já foram feitas no modelo de dados para que vários atributos, métodos de busca e outras coisas mais estejam disponíveis. E ainda, é possível expor o modelo por webservices REST com pouco esforço e sem que haja a necessidade de duplicar as definições de atributos. Muito mais simples, muito mais poderoso, muito mais inteligente e muito menos trabalhoso. Não é a toa que essas ferramentas estão revolucionando o mercado de desenvolvimento de software.

Na era que estamos, onde trabalhamos na maioria das vezes com linguagens orientadas a objeto que favorecem muito a modularização e componentização, é muito mais inteligente pensar em modelos onde você precisa de um mínimo de configuração para que muitas coisas aconteçam, e não em modelos onde é preciso gerar um monte de código para “n” camadas.

É por todos esses problemas que as ferramentas de MDA nunca foram para frente, apesar da idéia estar no mercado há vários anos. Talvez um dia elas funcionem, mas hoje em dia não há nada melhor do que usar bons princípios de programação, como os que eu exemplifiquei acima.

Eu até pensei em escrever um post a respeito desse assunto mas o Phillip Calçado já escreveu pelo menos dois e eu não tenho nada muito relevate a complementar. Recomendo a leitura:

http://blog.fragmental.com.br/2008/07/25/uh-eme-ele/
http://blog.fragmental.com.br/2008/01/20/programacao-radioativa/

[ ]s, gc

Não lembro aonde li a respeito, mas sempre me passa pela cabeça a história do programador preguiçoso.

Bons programadores são preguiçosos, pois não gostam de perder tempo com problemas simples e repetitivos.

Frameworks, code generation, scripts, está tudo aí, pronto para utilizar.
Basta investir algum tempo e o retorno certamente será apreciável.

O trabalho repetitivo, deixemos para os pouco criativos.

Muito legal o post Guilherme, eu sempre que posso e mesmo quando não posso eu faço esse investimento pensando em “multiplicar” o tempo que estar por vir acho que é por ai mesmo que devem andar as coisas, mas ficar reclamando que o prazo não dá realmente não resolve nada. mas mesmo assim fica difícil conseguir fazer sozinho, é como você disse tem que ter força de vontade e não adianta fazer sozinho e isolado por que não será somente você usará o recurso, todos tem que apoiar a iniciativa para realmente ela acontecer.
Muito bom encontrar esse seu post, parabéns continue evoluindo.

Peace

Excelente post Guilherme.

Esse talvez tenha sido o principal motivo deu ter criado o projeto J2EE Spider (http://www.j2eespider.org) a alguns anos atrás.

O objetivo não era “gerar” um sistema pronto pra mim, mas sim utilizar um template que eu defini para eliminar tarefas repetitivas de projetos.

Isso vai desde a eliminação da criação de scripts de build até a eliminação da codificação de CRUDs baseado no modelo (rails / django like).
Mas como eu disse tudo isso de uma forma customizável e sem precisar aprender muitos comandos para executar essas operações.

Mas enfim, eu acho esse foco em produtividade fantástico. Sou suspeito para falar 😛

Oi Guilherme,

Também sou louco por automação. Desde backup, deploy remoto via ssh, alteração de configurações de projetos (imagine ter dois ambientes, um de desenvolvimento, outro de aceite; dependendo do projeto, pode haver uma quantidade considerável de arquivos de configuração apontando as base de dados correta, etc.), configuração de servidores, dentre outros. Um script interessante que eu fiz recentemente foi para baixar e empacotar plugins do eclipse, dessa forma não preciso baixar vários plugins toda vez que instalo o eclipse em uma máquina nova, ou atualizo o mesmo. A maioria dos scripts que faço são com groovy e ant. 😀

Eu costumo dizer que qualquer coisa que se precise fazer mais do que 1 vez merece ser automatizada.

Se a automação for simples, eu já procuro fazer um script na hora, porque aí nem compensa esperar a 2a vez. Se eu precisei fazer qualquer coisa uma segunda vez, obrigatoriamente farei o script antes de executá-la, com base dos passos levantados na primeira execução.

Tem funcionado.

Interessante o seu relato de uso.
Sempre que possível tento automatizar o máximo possível e dá para notar claramente como isso aumenta minha produtividade.
Além desse conselho, para evitar perda de tempo, só o de fazer as coisas bem feitas, para também evitar ter que refazer e ter o dobro do trabalho.

[]s

Muito bom GC!!! Em relação ao prazo nos comentários, sempre vai estar apertado e se leva um tempo para conseguir automatizar, levará menos futuramente e outras coisas podem ser exploradas, além de evitar o erro humano natural. Enquanto os testes rodam, uma partidinha de Pro evolution soccer, ou diminuir o tempo de build para 1 minuto 🙂

Leave a Reply to Lucas de Castro Cancel reply

Your email address will not be published. Required fields are marked *