Autonomia & Tecnologia

O que é Make it Work, Make it Right, Make it Fast

0

Por sugestão do meu amigo Vinícius Braga, decidi traduzir para português o meu post original The make it work, make it right, make it fast misconception.

Quando se trata de desenvolvimento ágil, um dos mantras preferidos dos programadores é: Make it Work, Make it Right, Make it Fast.

No entanto, é comum vermos pessoas reclamando que ao seguirem esta direção, seus projetos nunca chegam à etapa make it fast. Isto acontece por uma má compreensão do conceito, fazendo com que as pessoas tratem cada um destes passos como ações isoladas de um projeto. E estas são apenas três etapas que precisam ser realizadas em uma mesma tarefa de desenvolvimento.

Quando você inicia uma tarefa de desenvolvimento, existe um estágio inicial onde você precisa explorar as possibilidades. Você não sabe exatamente qual a melhor abordagem para resolver o problema, mas tem algumas idéias. Nesta etapa, se você buscar desenvolver de imediato O MELHOR código para solucionar a questão, certamente você despenderá uma enorme quantidade de tempo nesta jornada.

No início de qualquer desenvolvimento, sempre existem muitas incertezas e você precisa descobrir através da experimentação, formas de reduzir o nível de incertezas para uma quantidade confortável para que você possa focar e implementar seu código. Este processo de experimentação é a etapa Make it Work, quando você apenas deve se preocupar em escrever algum código que lhe proporcione um comportamento próximo ao desejado. É quase um rascunho.

Logo em seguida, provavelmente você já descobriu quais bibliotecas usar, como o código que já existia interage com este novo comportamento, etc. Este é o momento de refatorar e fazer direito! Ou seja: Make it Right. Agora você deve eliminar códigos duplicados e organizar seu código corretamente buscando uma boa arquitetura e garantindo a facilidade de manutenção do código.

Na vida de todo Desenvolvedor de Software, uma grande verdade é que as restrições estão em toda parte. E exatamente por isso precisamos a todo tempo balancear a relação entre arquitetura e desempenho. Programar buscando inicialmente um alto desempenho é muito complicado. Por isso, após conseguir uma boa arquitetura para seu código, você deve torná-lo rápido: Make it Fast. Respeitando as etapas nestas ordem, sua tarefa será muito mais simples, pois você poderá analisar o seu código e identificar quais os 20% de código que você precisa otimizar para conseguir uma melhoria de 80% no desempenho. É o Princípio de Pareto puro e simples!

Ao final destes três estágios, você terá concluído o desenvolvimento de sua tarefa, e poderá integrar seu código ao projeto, entregando o valor desejado para o seu Product Owner.

Se você ignorar alguma destas etapas enquanto executa a implementação de uma tarefa, muito provavelmente irá sofrer com os efeitos devastadores causados por big design up front, débito técnico, e um sistema com desempenho medíocre.

Para completar, fica aqui um último conselho: Cuidado para não compensar péssimas estimativas de tempo entregando software que simplesmente “funciona”. Se isto se tornar um hábito, eu garanto que você terminará com um Projeto Espaguete Não Testado onde o custo de mudança será tão alto que poderá colocar o seu negócio em risco e sua “agilidade” será inútil.

[]’s!

você pode gostar também