5 erros comuns em C# que tornam seu software impossível de manter — explicados por Derek Comartin

1. Falta de propriedade sobre o Estado

Derek começa por identificar o erro de permitir que várias fronteiras ou serviços atualizem dados compartilhados sem uma definição clara de responsabilidade. Ele usa um exemplo em que o sistema de faturamento acessa outra parte do aplicativo e altera seu estado. Isso leva a problemas de consistência de dados, principalmente quando esse objeto reside em um local diferente dentro do sistema.

Essa abordagem de "vale tudo" gera erros, levando os desenvolvedores a se perguntarem: "Por que esses dados estão incorretos?" ou "Quem os alterou?". Derek enfatiza a importância de definir a responsabilidade. Cada parte do sistema deve expor uma API ou método bem definido, responsável por gerenciar o estado.

Em vez de permitir que qualquer parte do aplicativo modifique dados compartilhados, Derek sugere a criação de comandos e consultas explícitas. Por exemplo, quando você deseja atualizar uma remessa, você emite um comando através de uma interface dedicada. Isso proporciona estrutura e evita vazamentos de recursos decorrentes de alterações não rastreáveis.

2. Código implícito vs. fluxos de trabalho explícitos

Segundo Derek, muitos sistemas dependem fortemente de operações CRUD (Criar, Ler, Atualizar, Excluir), mas isso resulta em fluxos de trabalho implícitos. O código é tecnicamente funcional, mas carece de clareza sobre o que faz. Se sua classe suporta apenas operações genéricas, o fluxo de trabalho real do negócio fica oculto.

Considere o seguinte exemplo: um motorista recolhe uma encomenda e é gerada uma guia de remessa. Se o sistema apenas executar o UpdateShipment, não fica claro se a alteração na string (como o número do conhecimento de embarque) se deve a uma coleta ou a uma correção. Derek destaca que devemos substituir atualizações vagas por operações explícitas como PickupStopLoaded.

Isso resulta em um código mais legível. Isso também auxilia no tratamento de exceções, pois quando ocorre uma exceção, por exemplo, o rastreamento da pilha indicará claramente qual operação falhou. Os métodos explícitos também contribuem para melhores padrões de codificação, já que cada função tem uma única responsabilidade.

3. Adicionando Indireção Inútil

Derek aborda a indireção — a inserção de camadas desnecessárias entre o método que chama o método e o método de destino. Ele ilustra isso com conexões de banco de dados. Um controlador pode chamar um serviço, que chama um auxiliar, que chama outro serviço, que finalmente executa a consulta por meio do Entity Framework.

Essa pirâmide de abstrações dificulta a identificação de problemas e a melhoria do desempenho. Embora a criação de abstrações possa ser útil, como encapsular interfaces IDisposable para melhor gerenciamento de recursos, Derek alerta para o perigo de exagerar nesse aspecto. Pergunte-se se sua abstração simplifica a API ou se apenas oculta uma dependência de terceiros que existe em apenas um lugar.

Em vez de criar camadas apenas por criar camadas, Derek sugere gerenciar o acoplamento diretamente. O excesso de indireção não só polui o código, como também aumenta o potencial de vazamentos de memória e enfraquece os benefícios da coleta de lixo.

4. Jogando o jogo "E se..."

O próximo erro identificado por Derek é a preparação para casos de uso hipotéticos que podem nunca acontecer — o que ele chama de "Jogo do E se...". Muitos desenvolvedores C# escrevem classes e funções flexíveis para atender a necessidades futuras. Por exemplo: "E se precisarmos dar suporte a dois idiomas?" ou "E se precisarmos mudar de tecnologia?"

Derek alerta que essa mentalidade leva a frameworks inchados e código excessivamente genérico. Ele menciona ter se deparado com lógica de concatenação de strings e wrappers de tipo de referência que ninguém entende porque servem apenas a um caso de uso real.

Em vez de se preparar para o desconhecido, Derek aconselha focar nos requisitos reais. Cada método e variável deve servir a um propósito atual e justificado. Funcionalidades não utilizadas apenas aumentam o custo de manutenção. Como Derek disse, não se trata apenas do tempo de desenvolvimento, mas também do custo total de propriedade. Se a sua implementação pública de um método booleano Equals, por exemplo, cobre todos os casos extremos imagináveis, mas nenhum que realmente ocorra, você terá desperdiçado um tempo valioso.

5. Gerenciamento inadequado dos fluxos de trabalho

Por fim, Derek discute o erro de tratar os fluxos de trabalho como blocos procedimentais em vez de etapas modulares. Ele usa um exemplo do mundo real: fazer um pedido online. Depois que o usuário conclui o processo de compra, o sistema cobra o valor no cartão de crédito e envia um e-mail de confirmação.

Se uma etapa falhar — por exemplo, o processo de pagamento — como seu código reage? Você quer reverter o pedido? Apareceu algum erro? Enviar um e-mail de erro? Derek explica que agrupar tudo isso em um único bloco cria uma complexidade incontrolável.

Ele recomenda projetar fluxos de trabalho como pequenas unidades isoladas que se comunicam por meio de mensagens. Utilizar operações de Task assíncronas e o comando yield return facilita o gerenciamento dessas etapas. Além disso, o uso da instrução using e do bloco using em torno de recursos externos, como acesso a arquivos ou conexões de banco de dados, pode ajudar a prevenir vazamentos de memória.

Por exemplo, um bloco using em torno de um fluxo garante que ele seja descartado corretamente — um ponto vital ao trabalhar com interfaces IDisposable. Quando os fluxos de trabalho se tornam complexos, essas boas práticas garantem que as exceções sejam detectadas e tratadas de forma eficaz, preservando o desempenho e a capacidade de manutenção.

Concluindo: Escreva código limpo e de fácil manutenção.

Como Derek conclui em seu vídeo às 12:45, ele reflete sobre esses erros não apenas como coisas que presenciou, mas também como coisas que ele próprio cometeu ao construir grandes sistemas empresariais. Essas são lições aprendidas com a experiência, e ele incentiva os espectadores a compartilharem seus próprios erros nos comentários.

O conselho de Derek aplica-se não só ao C#, mas também a muitas outras linguagens. Quer você esteja trabalhando com comparação de strings, métodos Equals() ou projetando novos recursos, a chave é clareza, intenção e manter seu código de fácil manutenção.

Se você tem interesse em aprimorar suas habilidades em C# e evitar essas armadilhas comuns, o canal do Derek oferece muitos recursos gratuitos sobre arquitetura de sistemas, padrões de projeto e dicas práticas de programação. Evitar apenas um desses erros pode melhorar significativamente a qualidade do seu projeto.

Então, da próxima vez que você começar a escrever código, lembre-se das palavras de Derek e pergunte-se: "Estou tornando isso mais complexo do que o necessário?"

Para mais conteúdo como este, confira o canal CodeOpinion de Derek Martin no YouTube.