A apresentação discute a relação entre "design smells" e práticas ruins de desenvolvimento, sugerindo uma abordagem para implementar melhores processos e refatorar uma arquitetura já existente
7. Globalcode – Open4education
Fluxo de caixa de um investimento
Por que o time to market é
tão importante?
Ponto de
maior prejuízo
Início da
Receita
Break even point
(ponto de equilíbrio)
8. Globalcode – Open4education
Fluxo de caixa de uma arquitetura deteriorando
Por que o time to market é
tão importante?
Ponto de
maior prejuízo
Início da
Receita
Break even point
(ponto de equilíbrio)
Despesas > Receitas
9. Globalcode – Open4education
Fluxo de caixa de uma aplicação sendo reescrita
Por que o time to market é
tão importante?
Ponto de
maior prejuízo
Início da
Receita
Break even point
(ponto de equilíbrio)
Despesas > Receitas
Início reescrita
Break evenNovo prejuízo
Tempo de vida de duas aplicações simultaneamente
sem qualquer evolução funcional
Retorno da nova aplicação
(se você sobreviver até lá!)
11. Globalcode – Open4education
Outros mitos e lendas sobre
reescrever aplicações
“Não faremos novas funcionalidades no sistema velho,
somente no novo…”
A pressão comercial ou do cliente interno será mais forte
Pressões por demandas regulatórias
“Como não teremos o custo de desenvolver na arquitetura
ruim, seremos mais rápidos…”
Toda nova funcionalidade escrita no sistema velho será uma mudança não prevista
Há o custo de migrar toda a base de clientes para a nova aplicação
Pessoas serão realocadas para resolver crises na aplicação em produção, que
atualmente sustenta a empresa
12. Globalcode – Open4education
Se reescrever não é a
saída, qual é a solução?
Design smells: Sintomas de um software que está apodrecendo
[UncleBob (2008)]
13. Globalcode – Open4education
Se reescrever não é a
saída, qual é a solução?
Qual é o processo de desenvolvimento usado nos legados?
14. Globalcode – Open4education
Se reescrever não é a
saída, qual é a solução?
Existe correlação entre processo e design smells?
15. Globalcode – Open4education
Se reescrever não é a
saída, qual é a solução?
Existe correlação entre processo e design smells?
16. Globalcode – Open4education
Se reescrever não é a
saída, qual é a solução?
Existe correlação entre processo e design smells?
17. Globalcode – Open4education
Se reescrever não é a
saída, qual é a solução?
Existe correlação entre processo e design smells?
18. Globalcode – Open4education
Se reescrever não é a
saída, qual é a solução?
Existe correlação entre processo e design smells?
19. Globalcode – Open4education
Se reescrever não é a
saída, qual é a solução?
Existe correlação entre processo e design smells?
20. Globalcode – Open4education
Se reescrever não é a
saída, qual é a solução?
Se fosse começar do zero, quais processos usaria?
[UncleBob (2008)] [Schwaber e Sutterland (2013)] [Beck(1999)] [Aniche(2012)]
21. Globalcode – Open4education
Por que você não implementa estes processos no seu legado?
Se reescrever não é a
saída, qual é a solução?
ISSO É LOUCURA! IMPOSSÍVEL! MINHA APLICAÇÃO NUNCA
VAI TER UM BUILD AUTOMATIZADO!
“Insanidade é continuar fazendo
sempre a mesma coisa e esperar
resultados diferentes”
Albert Einstein
22. Globalcode – Open4education
Se reescrever não é a
saída, qual é a solução?
Mas com todos esses processos, não vou ficar menos produtivo?
Tempo
[UncleBob (2008)]
23. Globalcode – Open4education
Por onde começar?
Script de build
Acompanhamento
de métricas
Integração
contínua
Controle de
versão
Automação
do Deploy
Testes unitários
Testes de
aceitação
Testes sempre
passando
Build sempre
compilável
Política de
versionamento
Script de deploy
Entregas
incrementais
Rastreabilidade
fonte/binários
• Disclaimer #1: O slide é uma proposta. Não é a única maneira de implementar
• Disclaimer #2: Parte-se do princípio cenário de caos. Em times maduros, é muito interessante os testes
unitários e de aceitação estarem associados à automação do deploy
24. Globalcode – Open4education
E depois?
Comece a refatorar a aplicação existente, em pequenas iterações
• Ajudam a identificar pontos problemáticos de código, acoplamento e
manutenção
• Diminui o medo de mudar
• Ativo importante para futuras mudanças
• Ajuda a extrair a lógica de domínio e evitar
apodrecimento do código
• Diminui o medo da mudança e
permite feedback rápido
26. Globalcode – Open4education
Referências
[UncleBob (2008)]: Robert C. Martin (2008). Clean code: a handbook of agile software
craftsmanship. 1a edição. Prentice-hall.
[Schwaber e Sutterland (2013): Ken Schwaber e Jeff Sutterland. The Scrum Guide (julho
2013). https://www.scrum.org/Scrum-Guide
[Beck (1999)]: Kent Beck (1999). Extreme programming explained: embrace change.
Addison-wesley
[Aniche (2012)]: Maurício Aniche. Test-driven development: teste e design no mundo real.
Casa do código.
Livros
Blog posts
Reescrever ou não reescrever, eis a questão: http://ericlemes.com/2010/06/01/processos-
reescrever/
Integração contínua: http://ericlemes.com/2014/02/03/integracao-continua/
Gestão de configurações e versões (SCM): http://ericlemes.com/2009/07/02/processos-scm/
Code metrics: http://leandrodaniel.com/index.php/code-metrics-parte-1-metricas-de-codigo-
sao-aliadas-do-arquiteto/
MSBuild in a nutshell: http://ericlemes.com/2012/04/22/msbuild/
The Joel Test: http://www.joelonsoftware.com/articles/fog0000000043.html