Praticando o desapego: quando ignorar a dívida técnica
Objetivo
Gerenciar o catálogo de produtos e categorias de um
dos maiores sites de e-commerce do mundo.
Equipe
● 4 times○ 35 desenvolvedores
○ 8 engenheiros
○ 6 gerêntes
Métricas do projeto
linhas de código
558982
Métricas do projeto
classes java
3096
linhas de código
558982
Métricas do projeto
junit tests
2777
linhas de código
558982classes java
3096
Métricas do projeto
linhas de código
558982
tempo de build
7 h
classes java
3096classes java
3096
Pontos de integração do projeto
Pontos de integração do projeto
104 pontos de integração!
Primeira estória
Importar produtos de um feed
Primeira estória
Importar produtos de um feed
IHateYouForverImpl
● 2272 linhas● 32 dependências● getItemStatus (3 setters)
Primeira estória
Importar produtos de um feed
IHateYouServiceImplTest
● 78 linhas de test setup
Primeira estória
Importar produtos de um feed
loadAllProducts.xml
● 26 páginas impressas
Primeira estória
Importar produtos de um feed
ProductDTO.java
● 86 atributos● + getters / + setters● equals() => 400 linhas
Vamos jogar tudo fora e começa do zero!
Tá bom, então vamos refatorar tudo!
Arrumando a casa
● refatoração intensiva
● pair programming
● reclamação
6 semanas mais tarde
Ferrou!
● um refectoring inocênte (especulativo)
● bugs em produção (custou dinheiro)
:(
● desconfiança entre o time● quase cancelamento do
projeto● iteration manager se demitiu● tech lead se demitiu
right software > software right
+/-
software certo > fazer software certo
Código legado é código que funciona!
Jogue os "gatos" pra debaixo do tapete
● hierarquias e classes paralelas● empacote em façades
:)
● mvp em nível de funcionalidade
● divide and conquer
Então, quando vale a pena refatorar?
● não dá pra medir com precisão
:)
● conheça suas ferramentas
● controle de versão
Oo"
● fazer tdd?...
Oo"
● fazer tdd?... NÃO!
será que esse sucesso é fruto do esforço inicial?