Dicas/ RIA

Jogar um código fora e refaze-lo do zero #soudev

Escrevi um Tweet ontem que muita gente que acompanha o #hastag #soudev pode concordar ou não, foram levantados alguns argumentos, como lá só tem espaço para 140 caracteres, deixa eu jogar aquele tweet fora e escrever do zero outro tweet aqui no Blog, onde tem mais espaço para eu mostrar quais motivos me levaram a isso.

Em resumo, o meu tweet foi :

Jogar um código fora e refaze-lo do zero, me retornou + performance +resultado +aprendizado #soudev

O real motivo:

Em um projeto onde trabalhamos temos um componente que é deveras complexo, e esse bendito componente acabou gerando outros 19 sub componentes, o que atingiu uma certa parte de grande esforço da equipe para concretiza-lo.
Um dos grandes obstáculos foi ter que cria-lo sem especificação técnica, ou seja no estilo Jack Bauer ou melhor, Mãe Diná (Prevendo as necessidades Rah!).

Impactou em 2 semanas escrevendo, 1 testando e 3 dias implementando, no resultado, o componente só funcionou 50% do que era previsto como achavamos que era para ser.

Então, no modo “faca na caveira” ou Coragem tecnicamente falando. Resolvemos que era mais fácil jogar fora todo o componente (leia-se parar de usar aquele código e criar outro do zero). Que fosse necessário para tal. Agora tendo a especificação pronta de fato, o levantamento de requisitos e os caprichos do pessoal de UX, só nos restou mãos a massa.

Em resumo, depois de 12 horas, o componente está criado, já testado e implementado no projeto.

Com isso nós ganhamos alguns itens:

Performance : O componente que era 19 sub-compontes ficou em apenas 11, De 6.700 linhas passou para 2.346 linhas, reduzindo os Skins do Flex para uma coisa bem mais simples e rápida, já que skins são ainda o gargalo do Flex 4.5.

Resultado: Com bem menos tempo e com um grande obstaculo pulado que foi na especificação, o resultado foi de 99% esperado pelo gerente de projeto e isso nos deu mais retorno sobre o que realmente importava nele.

Aprendizado: Aprendemos que o modo Mãe de Diná, não funciona em projetos, ter bola de cristal é sempre um 171, Optimizamos várias formulas matemáticas que eram utilizadas nele, re-criar a roda não vale a pena e sempre fica faltando um parafuso. Onde nos levou a usar algumas classes dessa biblioteca.

Quando você escreve um código,uma vez, ele se torna fácil nas próximas vezes que você for fazer em seguida. O grande problema e você julgar se isso realmente é necessário ou não. Depende muito de cada projeto, entre os fatores como: Quem está bancando o projeto, Prazo, estimativas de hora, Quantidade de mão de obra necessária.

Pense nisso.

Deixe uma resposta

O seu endereço de email não será publicado. Campos obrigatórios são marcados com *