Profissionais TI - Pra quem respira informação

Assunto polêmico, hein?

Bom, pessoal, sempre abordei os dois temas mencionados no título deste artigo.

O primeiro preza pela objetividade, expressividade e legibilidade do código, com base em refatorações contínuas e implementação de testes. O segundo contempla uma série de metodologias para aumentar a velocidade na entrega de funcionalidades. Dado o propósito de cada um, é correto afirmar que, se valorizarmos mais um deles, o outro será negligenciado?

No cenário atual de desenvolvimento de software, muitas empresas procuram investir recursos em metodologias ágeis para aprimorar o prazo e a comprometimento das entregas. Outras, por sua vez, investem mais na estrutura do projeto para garantir um produto com menos defeitos. Sendo assim, chegamos a um impasse:

• Se investirem em Clean Code para manter o projeto sustentável, terão que reduzir a quantidade de entregas, já que uma parcela considerável de tempo será consumida para a codificação de testes automatizados, refatorações, aplicações de princípios e acompanhamento de métricas;
• Se investirem em Desenvolvimento Ágil para agilizar as entregas, terão que reduzir o foco constante em atividades relacionadas à qualidade técnica, como TDD e Clean Code.

É mesmo um impasse? Não! A resposta é clara e direta: pense a longo prazo.

Hora de esclarecer melhor…

Quando um projeto é pequeno, Clean Code pode soar como algo desnecessário. Afinal, qual o motivo de investir tempo em um código que raramente será alterado? Não só Clean Code, mas também o uso de outras práticas e ferramentas, como Code Review, Integração Contínua, TDD, padrões e métricas. É como se utilizássemos um tanque de guerra para matar uma formiga.

Agora me respondam: quantos projetos são assim? Como é possível calcular o limite da dimensão de um projeto?

Por fim, caímos em um erro tradicional: o projeto cresce, cresce, cresce e, quando menos esperam, há várias classes, módulos, pacotes e componentes com uma arquitetura toda comprometida, já que, lá no início, o projeto nasceu sem uma cultura de sustentabilidade. Ninguém pensou a longo prazo.

Diante disso, o cenário se inverte: no começo, foi evidentemente mais rápido desenvolver o projeto sem as práticas de Engenharia, como Clean Code. Agora, no entanto, a expansão e as correções do projeto serão muito mais custosas em virtude da falta dessas mesmas práticas. Irônico, não?

A partir daí, o projeto está fadado a ser uma colcha de retalhos. Quando surge um bug, a correção será mais uma condição IF em um método. Modificar classes básicas? Praticamente impossível! O desenvolvedor altera uma linha e derruba a consistência de tudo o que é dependente, como uma epidemia de bugs. Falo sério! Isso acontece muito!

Para descobrir se um projeto se encontra nesse nível, pense em uma classe que foi escrita sem as práticas de Clean Code e responda duas perguntas:

1. É possível estendê-la? A resposta provavelmente será “Sim”.
2. Será fácil? Se a resposta for “Não”, é uma má notícia.

Além disso, não se esqueçam dos testes. Sem TDD, o projeto não tem testes unitários, logo, à medida que o projeto cresce, mais testes manuais serão necessários para garantir a qualidade, principalmente testes regressivos. Se não houver automação, o tempo de testes será evidentemente maior, resultando no atraso de futuras entregas.

Mas e a questão da controvérsia com o Desenvolvimento Ágil?

Pois bem, como já repeti em outros artigos, a proposta do Desenvolvimento Ágil não é essencialmente a agilidade, mas a eficiência da equipe. É o amadurecimento da capacidade técnica, da colaboração e da comunicação entre os membros. A qualidade das entregas está proporcionalmente relacionada com a eficiência da equipe ágil. A agilidade é uma consequência da eficiência.

Portanto, vamos refletir. Se um desenvolvedor:

• Perde tempo tentando entender o código de outro desenvolvedor, perde-se a eficiência;
• Precisa de tempo para interpretar um método de 300 linhas, também perde-se a eficiência;
• Passa horas tentando descobrir uma hierarquia de classes e suas dependências, mais uma vez, perde-se a eficiência;
• Precisa de uma Sprint inteira para alterar um módulo básico sem quebrar todo o sistema, perde-se consideravelmente a eficiência.

Em outras palavras, se a ideia do Scrum é tornar a equipe mais eficiente, não há como atingir esse aspecto sem as práticas de Engenharia de Software. Ponto final. A disciplina de Engenharia de Software não surgiu por acaso e muito menos para ser utilizada exclusivamente em projetos de médio ou grande porte. Se alguém pensa assim, pensa errado.

Minha opinião: independente da dimensão do projeto, se for para fazer algo, faça bem feito. Caso contrário, é muito provável que um projeto que nasceu ágil se transforme em um caos, gerando custos excessivos para a empresa. Na verdade, será um projeto que não tem mais nada a ver com agilidade.

Antes de concluir o artigo, vale destacar que não existe controvérsia, ou impasse, entre esses dois assuntos. Se uma empresa investe em Clean Code, ela está, indiretamente, investindo também em Desenvolvimento Ágil. A Engenharia de Software e suas práticas existem para evitar que projetos ágeis percam essa característica com o passar do tempo. 

Pense a longo prazo.

Abraço!