Minhas reflexões sobre programação

Quando era mais novo, descobri que podia criar jogos com programação. Essa foi a centelha que me levou a seguir carreira em programação.

Mas anos depois, no meu estágio, comecei em desenvolvimento web e mudei meu foco. Tudo era novo e eu estava ansioso para aprender sobre frontend, backend, bancos de dados e IA.

Então, me interessei pelas melhores práticas. Eu me perguntei: “Como escrevo um código melhor?” Isso me levou a aprender Código Limpo, SOLID, Design Patterns, Arquitetura Limpa, Domain Driven Design (DDD). Achei que sabia tudo o que havia para saber sobre arquitetura de software. Eu acreditava que poderia projetar qualquer software. Não havia mais nada para aprender.

Mais tarde, encontrei um livro intitulado: “SOLID não é SOLID”. Foram os melhores seis dólares que já gastei. O autor mostrou que o SOLID não ajuda e deu exemplos claros.

Foi o primeiro prego no caixão das chamadas melhores práticas.

Também comecei a aplicar Arquitetura Limpa no frontend só para ficar desapontado. Apliquei isso em projetos pessoais e relacionados ao trabalho apenas para perceber que se tornava um código-fonte inchado com tantos arquivos com apenas cinco linhas ou menos. Tudo parecia errado, mas é assim que os ‘especialistas’ dizem para estruturar seu código.

Outro prego no caixão.

Então, vi alguns vídeos e postagens em blogs sobre software em declínio.

O software tornou-se inchado e complexo. A grande maioria dos softwares é lenta, inchada e não confiável. Um dos motivos é que criamos regras, as chamadas melhores práticas, que deveriam melhorar o tempo do desenvolvedor, mas não há evidências desse resultado. Para piorar ainda mais as coisas, inventamos muitas desculpas sobre por que as coisas são assim e que não podemos fazer nada a respeito para criar um software melhor. Perdemos completamente o controle da qualidade do software. Perdemos tempo e energia regurgitando as melhores práticas para novos desenvolvedores.

Também usamos desenvolvimento orientado por hype. Usar a tecnologia mais recente em produção sem considerar os prós e os contras, como a moda dos microsserviços. Isso ajuda a tornar o software mais difícil de desenvolver.

Reinventamos a roda em coisas básicas como operações CRUD em vez de usar um framework como Rails. Estamos perdendo tempo e energia usando o ecossistema JavaScript. Não há nada de errado em reinventar a roda, mas a nossa roda é pior.

Usamos React.js onde não é necessário, e o próprio React.js é uma abstração pobre que precisa de uma estrutura, estado e busca de biblioteca para aumentar o inchaço e funcionar corretamente. Tudo isso para fazer algumas páginas web com formulários e validação.

Tanta engenharia excessiva!

Podemos criar um software melhor que seja rápido, confiável e de fácil manutenção.

Concluindo, você deve ignorar todas as regras, diretrizes ou modas abstratas aleatórias ou, pelo menos, encontrar uma maneira de medir para provar que elas trazem benefícios para o seu caso de uso.

Meu conselho para todo programador é:

Esqueça todas as práticas recomendadas. É tudo inútil. Concentre-se em problemas reais. Programar consiste em mover dados de um lugar para outro. Só isso.

Aqui está uma lista de coisas que você deve ignorar e uma breve explicação de por que penso assim:

Ignore Clean Code

Você pode escrever um bom código sem ler Clean Code. Ler código limpo não torna seu código bom.

Ignore DRY

Seguindo DRY, você pode criar a abstração errada.

Ignore Refatoração

O livro Refactoring é inútil porque se concentra muito em POO. As únicas técnicas que acho que valem a pena usar são:

Além disso, dê uma olhada em compressão semântica.

Ignore SOLID

Leia o livro

Ignore Design Patterns

O único propósito é corrigir deficiências na linguagem, especialmente nas linguagens OO. Os autores concordam que alguns padrões não fazem sentido em outra linguagem porque possuem mecanismos melhores para resolver um problema. O trecho do livro:

…alguns de nossos padrões são suportados diretamente pelas linguagens orientadas a objetos menos comuns. O CLOS possui vários métodos, por exemplo, que diminuem a necessidade de um padrão como Visitor (página 331). Na verdade, existem diferenças suficientes entre Smalltalk e C++ para significar que alguns padrões podem ser expressos mais facilmente em uma linguagem do que em outra. e a maioria dessas linguagens existia antes de Java e C++, que são as linguagens alvo do livro.

O padrão de Strategy, por exemplo, já existia muito antes do livro. Em C você poderia passar um ponteiro de função para uma função de ordenação

Ignore Arquitetura Limpa

A Arquitetura Limpa é superestimada e desnecessária. Não faz sentido discutir cada variante e suas diferenças. (ports e adapters, onion, hexagonal). Você pode obter código modular e testável sem Arquitetura Limpa.

Se você realmente deseja Arquitetura Limpa, pode aplicar funções puras ao seu código.

A partir de uma experiência pessoal com Arquitetura Limpa, Escrevi um gerenciador de receitas para minha mãe. É um aplicativo simples com operações CRUD em uma tabela de receitas. O problema é que as receitas estão em português e as palavras em português têm acento. Então, para fazer a busca funcionar, eu precisava de uma extensão Postgres para remover os acentos da consulta de pesquisa e do título da receita. Mesmo ao aplicar Arquitetura Limpa, meu código estava vinculado ao banco de dados e eu não poderia substituí-lo se quisesse. Foi crucial para a solução.

Ignore DDD

O DDD é superestimado e desnecessário mesmo em projetos complexos. Você não precisa de DDD para melhorar a comunicação.

Lembre-se de que não existe bala de prata.

Ignore POO

Não há provas de que POO ofereça qualquer benefício.

POO geralmente leva a um desempenho ruim:

Vários livros tentam corrigir POO:

“Heurísticas de Design Orientado a Objetos” por Arthur J. Riel.
“Pensamento de Objeto” por David West
“Objetos Elegantes” (Vol. 1 e 2) por Yegor Bugayenko

Esses livros mostram que POO é falho visto que eles fornecem diretrizes para escrever melhor código orientado a objetos. São cerca de 1200 páginas de heurísticas! Tente se lembrar de tudo isso!

Michael Feathers escreveu em seu blog dizendo que seu livro “Trabalho Eficaz com Código Legado” deve ser denominado “Trabalho Eficaz com Código Orientado a Objetos”. Ele também diz que o código funcional é um código honesto.

Existem muitos projetos não OO bem-sucedidos: Git, Linux, Redis, Nginx, Postgres e SQLite. Você pode escrever software de sucesso em POO, procedural e até mesmo em assembly.

Linguagens modernas, como Rust, Go e Erlang, não adotam explicitamente a POO e não a incentivam, e algumas linguagens mais antigas estão se afastando do paradigma. Aplica-se a Java, C# e C++.

Ignore Dublês de Teste e TDD

Ignore a terminologia de dublês de teste. Tudo que você precisa são de dados e uma função para fins de teste. Esqueça a pirâmide de testes. Concentre-se em testes de integração. Concentre-se em escrever testes, não em TDD.

Lembre-se sempre de que software sem testes não pode ser mantido.

Jonathan Blow em testes unitários e TDD

Ignore microsserviços e microfrontends

Microsserviços e microfrontends são o reflexo da lei de Conway. O mesmo se aplica à separação de frontend e backend. Na maioria das vezes, você não precisa de microsserviços, apenas para alguns casos específicos.