A Importância do Pensamento Acadêmico no Desenvolvimento de Software

Disclaimer

Este texto foi inicialmente concebido pela IA Generativa em função da transcrição de uma live do Dev Eficiente. Se preferir acompanhar por vídeo, é só dar o play.

Introdução

No desenvolvimento de software, constantemente adotamos práticas e metodologias baseadas em crenças amplamente aceitas pela comunidade. Acreditamos que Clean Code nos leva a ter um código mais fácil de manter, que Domain Driven Design resulta em sistemas mais sustentáveis, ou que escrever mais testes torna nosso sistema mais confiável. Mas e se algumas dessas crenças não fossem tão sólidas quanto imaginamos? Neste post, vamos explorar como o pensamento acadêmico pode nos ajudar a questionar nossas práticas de desenvolvimento de forma saudável e construtiva.

O Poder das Crenças no Desenvolvimento

Todos nós, desenvolvedores, temos nossas crenças sobre as melhores práticas. Algumas das mais comuns incluem:

Aplicar as ideias do Clean Code nos leva a ter um código mais fácil de ser mantido
Aplicar Domain Driven Design resulta em sistemas mais sustentáveis a médio e longo prazo
Determinados modelos de escrita de histórias de usuário fazem com que sejam mais facilmente entendidas, gerando mais velocidade na implementação
Quanto mais testes escrevemos, mais confiável é nosso sistema
Para lidar com problemas em produção, é essencial ter conhecimento profundo sobre o sistema
Escrever testes antes do código nos faz testar mais e guia a produção do código a um design mais adequado

Essas crenças podem fazer sentido e muitas vezes são baseadas em experiências práticas. No entanto, o que o pensamento acadêmico nos ensina é uma lição valiosa: não importa o que acreditamos, sempre podemos estar errados.

Questionando o Modelo INVEST

Vamos analisar um exemplo concreto: o modelo INVEST para escrita de histórias de usuário. Este acrônimo significa:

Independente
Negociável
Valorosa
Estimável
Spequena
Testável

Este modelo é amplamente difundido e acredita-se que seguir essas diretrizes resulta em histórias mais auto-explicativas, que geram menos dúvidas e possibilitam que as equipes trabalhem de forma mais fluida.

Porém, uma pesquisa acadêmica intitulada "Analyzing the INVEST Model in Agile Software Development" trouxe descobertas interessantes. O estudo analisou 256 textos da internet e 33 artigos científicos sobre o modelo INVEST e descobriu que:

Muitas fontes discutem o INVEST como uma ferramenta crucial, mas não trazem nenhuma prova
Os benefícios geralmente são apenas teóricos
Quase nenhum texto da internet traz casos de estudo ou análises que evidenciem a efetividade do modelo
Há uma tendência de simplesmente repetir informações do artigo original

Isso contrasta com outras práticas, como testes automatizados, onde já existe literatura suficiente mostrando correlação entre volume de testes (considerando qualidade) e confiabilidade do sistema.

O Mito da Refatoração Sempre Benéfica

Outro exemplo interessante é a crença sobre refatoração. Tendemos a acreditar que refatorar sempre melhora o código, mas estudos mostram que vários códigos pós-refatoração apresentam métricas de saúde piores do que o código pré-refatoração.

É importante distinguir dois tipos de refatoração:

Refatoração técnica: para reorganizar o código quando ele está atrapalhando a evolução do sistema
Refatoração de aprofundamento: quando você entende o negócio de maneira diferente e o código anterior não é mais suficiente

A lição aqui é que refatorar sem técnicas adequadas, sem um checklist do que você quer ver na versão refatorada, pode não trazer os benefícios esperados.

Troubleshooting: Método vs. Experiência

Duas áreas frequentemente subestimadas no desenvolvimento são engenharia de requisitos e troubleshooting. Sobre troubleshooting, uma crença comum é que não adianta treinamento específico, pois os problemas variam muito e só se aprende passando por cada situação.

No entanto, pesquisas mostram que embora o domínio do contexto seja importante para resolver problemas em produção, a diferença entre uma pessoa experiente e uma inexperiente pode ser diminuída através de treinamentos que ensinem métodos para derivar hipóteses e resolver problemas sistematicamente.

Pessoas que têm tanto o conhecimento do contexto quanto métodos estruturados de troubleshooting tornam-se ainda melhores resolvedoras de problemas. Isso questiona a crença de que essa capacidade vem apenas da exposição reativa aos problemas.

A Importância da Dúvida Saudável

O pensamento acadêmico nos ensina a questionar constantemente nossas práticas, mesmo aquelas que parecem óbvias. Podemos aplicar essa mentalidade a diversas outras práticas:

Object Calisthenics realmente deixa o código mais interessante e fácil de manter?
A Arquitetura Limpa de fato torna sistemas mais limpos e fáceis de evoluir?
Ela realmente consegue isolar o core do sistema de tal forma que mudanças futuras não o afetem?

Conclusão

O objetivo não é descartar todas as práticas que utilizamos, mas sim adotar uma postura de questionamento saudável. Independente das nossas crenças, devemos sempre considerar que podemos estar errados e buscar evidências que sustentem ou questionem nossas práticas.

Essa mentalidade científica nos permite evoluir continuamente como profissionais, abandonando práticas que não agregam valor real e refinando aquelas que realmente fazem diferença. Afinal, no final das contas, queremos entregar software que gere valor real para o cliente final, com alta qualidade e da forma mais eficiente possível.

Algumas Referências

Dev+ Eficiente

Se você gostou deste conteúdo, conheça a Jornada Dev + Eficiente, nosso treinamento focado em fazer com que você se torne uma pessoa cada vez mais capaz de entregar software que gera valor na ponta final, com máximo de qualidade e eficiência.

Acesse https://deveficiente.com/oferta-20-por-cento para conhecer tudo que oferecemos.