O que podemos aprender com: YAGNI - You aren´t gonna need it (Você não vai precisar disso)

Já ouviu falar do princípio YAGNI? Até alguns meses atrás eu não conhecia, mas quando o estudei e coloquei em prática no dia a dia, minha produtividade dobrou. Se ainda não conhece o princípio, você precisa ler este artigo e outros. Depois separe um tempo para pensar como pode aplicar em seu dia a dia. Afinal, qual a verdadeira vantagem de aplicar o YAGNI no seu trabalho ou projeto? Vamos entender!

De onde surgiu a expressão?

O primeiro profissional a fazer uma referência escrita foi Ron Jeffries, que é um dos três fundadores da metodologia de desenvolvimento de software Extreme Programming :

Além disso ele foi mencionado nesses livros:

• Refactoring: Improving the Design of Existing Code
• Lean Software Development
• Extreme Programming examined
• Extreme Programming Installed

No próprio artigo, Jeffries faz esse seguinte comentário:

"Sempre implemente as coisas quando você realmente precisa delas, nunca quando você apenas prevê que precisa delas"

Essa frase já diz muito. Mas para que fique mais claro, vamos contar uma história real que presenciei, mas obviamente com nomes e contextos bem diferentes.

A História de Tom

Tom acabou receber uma demanda que envolve criar uma rotina no sistema do cliente com o objetivo de mover arquivos de uma pasta para outra. Existe uma hora e data específica para acontecer essa tarefa dentro do sistema. Quando inicia o desenvolvimento da funcionalidade, Tom prevê uma situação ou uma futura necessidade que o cliente possa ter. Baseado no seu conhecimento e experiência com regras de negócios, decide implementar essa funcionalidade no sistema sem consultar o time de desenvolvimento e seu cliente. Depois de criar a funcionalidade principal, inicia o desenvolvimento da segunda função que foi sua previsão. Criar a lógica da funcionalidade traz algumas horas a mais de trabalho, pois ela tem uma classe própria e depende de uma etapa importante do sistema para funcionar. E o mais importante de tudo é que se Tom é um desenvolvedor experiente que se preocupa em seguir boas práticas, com certeza seguiu os princípios do Clean Code (Robert Cecil Martin) para deixar seu código claro e realizou Testes Unitários para garantir que as novas funcionalidades estejam conforme especificado.

Legal! Agora é o momento de Tom apresentar em uma reunião as novas funcionalidades do sistema. Mas a apresentação não está sendo feita para todos os envolvidos e usuários do sistema, apenas um representante da equipe de negócios, que vamos chamar de Mike, está presente e fica satisfeito com tudo o que foi feito! E agora os usuários tem uma funcionalidade a mais no sistema que podem utilizar. Passam alguns dias e semanas. Tom quer um feedback sobre como está aquela funcionalidade a mais que adicionou, então questiona:

-- Mike, a sua equipe está tendo alguma dificuldade em usar a funcionalidade extra que eu adicionei no sistema? Tem algum feedback?

Mike olha confuso e pergunta:

-- Qual funcionalidade? Aquela que você adicionou a mais?

-- Sim exatamente essa. - Tom responde já um pouco desconfiado.

Mike então responde:

-- Ah sim! Eu analisei em uma reunião com toda a equipe de negócios e alguns gestores, particularmente gostei da funcionalidade extra, mas os outros envolvidos não enxergaram como ela seria útil no momento. Até ia comentar isso com você mas acabei esquecendo, tem como ocultar aquela opção do sistema? Quem sabe podemos usar no futuro!

Você achou que essa história terminaria bem. Infelizmente isso não aconteceu. Qual foi o problema aqui?

Problemas de não seguir o YAGNI

O problema está em criar códigos, ou seja, funcionalidades sem antes ter certeza de que isso é realmente necessário! No caso de Tom ele criou apenas uma funcionalidade a mais. Mas imagine se ele tivesse entidades ou regras de domínio que tem certo grau de complexidade. É algo que precisamos nos atentar. Isso pode tomar proporções grandes, principalmente se tentar prever tudo. Isso pode destruir um software, perder prazos de entregas, sobrecarregar o sistema com métodos que nunca são chamados e principalmente sobrecarregar a equipe de desenvolvimento com funcionalidades que serão inúteis para o usuário final. É um assunto sério.

Pode estar pensando:

Não temos direito a opinar sobre alguma funcionalidade ou dar sugestões de melhorias?

Sim podemos! Mas é importante levar isso para os responsáveis (Product Owner e Gestores) pelo projeto e conversar, principalmente quando a empresa tem uma hierarquia. Se avaliarem que faz sentido para o contexto atual da aplicação (sistema) e que é realmente necessário, a melhoria pode ser adicionada ou será criada uma funcionalidade. O problema está em desenvolver sem consultar todos os envolvidos, sem aprovação, simplesmente porque você acha que isso é útil para os usuários.

Veja uma desculpa muito comum: "Vou deixar pronta essa funcionalidade agora, para poupar tempo mais tarde, tenho certeza que vão pedir isso."

Pessoal, desenvolvedores tem muitas funções a cumprir dentro de um projeto, obviamente dependendo do número de programadores em cada time. Às vezes um desenvolvedor só tem que cuidar do frontend, backend, base de dados, interface do usuário e as vezes até conversar com o cliente... e agora temos que prever o futuro também? Não temos como prever exatamente qual vai ser a nova feature exigida pelo usuário (cliente), então pense:

• Se você realmente não necessita de tal funcionalidade agora, não implemente! É perda de tempo. Concentre-se no que você está fazendo, na classe que está construindo e como pode melhorar ela aplicando boas práticas.

• Tempo é valioso e não podemos recuperar. Não compensa gastar ele para criar código que provavelmente não será usado. Use esse tempo para melhorar, refatorar ou até mesmo estudar melhor seu código.

Agora para reforçar tudo isso veja o que Ron Jeffries escreveu:

• Você está pensando sobre como a classe pode ser, ao invés do que deve ser. Você estava em uma missão quando começou a construir essa classe. Continue nessa missão, em vez de se distrair por um momento sequer.

• Seu tempo é precioso. Aprimore seu senso de progresso para se concentrar na tarefa real, não apenas em desenvolver o código.

• Você pode não precisar disso. Se isso acontecer, o tempo que você gasta implementando o método será perdido; o tempo que todo mundo gasta lendo será perdido; o espaço que ocupa será desperdiçado.

Nem precisamos comentar muito sobre as palavras de Ron Jeffries. Tenha foco e se concentre em aproveitar o tempo da maneira correta.

Benefícios de seguir o princípio YAGNI

Quando você enxerga importância de seguir o YAGNI, colhe muitos benefícios:

• Menor estresse e decepções: E se o seu método (palpite), foi para produção e de forma inesperada causar um bug que precisa ser corrigido em um final de semana? E justo nesse final de semana você prometeu sair com sua família. Você ganhou tempo prevendo a funcionalidade? E se o código que você escreveu, prevendo economizar tempo, está causando erros nos testes unitários do software? E se ao dedicar tempo ao criar esse método, você esqueceu de um detalhe na principal funcionalidade pedida pelos usuários, justo na que realmente vai para produção? Se tivesse concentrado todo o tempo no que realmente importava tudo isso não teria acontecido. Existem várias situações que podem gerar estresse desnecessário. Seja paciente e inteligente, evite código que não será utilizado agora!

• Economia de Dinheiro: Isso é algo sério. Pode ser difícil de imaginar. Presenciei um projeto de 2 anos ser jogado no lixo por excesso de funcionalidades que nunca foram usadas pelo usuário final. Os recursos a mais só traziam atrasos no prazo de entrega. E com isso a empresa perdeu dinheiro. Por que? Porque o tempo anda de mãos dadas com o dinheiro. Isso é fato! Projetos mal planejados, não conseguem gerar lucro. Empresas medem o tempo de produtividade e agilidade de equipes para saber exatamente o quanto será necessário investir em desenvolvimento de um Software e se o investimento de tempo e dinheiro realmente trará resultados.

• Economiza tempo: Nem preciso destacar muito nem prolongar. Tempo é algo que não é possível recuperar. Por isso faça o que foi pedido e foque para entregar com qualidade!

• Menos código para testar: Se você testa seu código e cria uma classe ou métodos responsáveis por algo que você acha que será usado, terá que reservar tempo para testar tudo isso.

• Melhora a qualidade do código: Faz sentido um método ou classe estar ali se ele nunca vai ser chamado (utilizado)? Obvio que não! Tente sempre deixar seu código o mais simples possível. Isso facilita a compreensão e evita que outros desperdicem tempo lendo um método que não é usado na aplicação.

Vou adicionar uma ilustração que Martin Fowler fez sobre o YAGNI em seu blog, se desejar ler o artigo escrito por ele, clique aqui para acessar:

Imagem do blog de Martin Fowler 👆

A imagem acima representa o que acontece quando você não segue o YAGNI. Repare que existe o Wrong Feature (podemos chamar de funcionalidade errada) que tem duas setas e a primeira aponta para Cost of building (para o contexto de software, podemos chamar de Custo de desenvolvimento) que é o esforço gasto na análise, programação e teste desse recurso. E a segunda seta segue para dois tipos de custos:

• Cost of Delay: Você poderia ter entregado a funcionalidade que realmente importa, em um prazo menor, se não tivesse parado para pensar em desenvolver funções que o sistema não precisa de imediato. Em consequência as próximas funcionalidades que serão exigidas, podem ter o tempo de desenvolvimento afetado.

• Cost of Carry: Você terá que arcar com o custo de manter todos os recursos desenvolvidos, principalmente aqueles que não estão sendo utilizados pelos usuários!

  Se você fizer da forma mais simples, "Right feature, built right..." (Recurso certo, construído da maneira certa), estará no caminho correto, terá menos estresse e vai conseguir desenvolver o sistema da maneira correta.

O que podemos concluir?

Seja objetivo, não tente prever o futuro do software baseado apenas em sua opinião. Faça o que foi pedido corretamente, com foco e qualidade. Caso julgue que sua previsão realmente faz sentido, não implemente o código antes de conversar com as pessoas que realmente estão usando a aplicação constantemente. Para você pode fazer sentido mas para o cliente não!

Fico por aqui nesse post, até o próximo 😀 !

Referência:

Martin Fowler. Yagni. 26 de maio 2015. Disponível em: https://martinfowler.com/bliki/Yagni.html/.