/ csharp-programming

Defensive Codding in C#

Em vários momentos onde a necessidade das boas práticas de programação são desafiadas em escopos legado, muitas vezes seu estilo de código, incluindo qualquer tipo de boa prática de programação acada vindo a ficar ameaçada pelo o conteúdo que o antecede.

Nessa postagem, vamos parametrizar o rápido entendimento dos fundamentos da programação defensiva em C#, especificamente aqui, vamos ver o que define um código limpo, conhecido como clean code praticies.

Dentro dos pilares que arquitetam a qualidade do código de determinada aplicação, podemos iniciar entendo algumas das caracteristicas dos tópicos encadeados da solução referente a boas práticas, como podemos ver na lista:

  • Fácil leitura e compreenção humana;
  • Intenção explicita;
  • Simples;
  • Minimal;
  • Pensado.

Quando definimos os aspéctos de algo bem feito, fica mais fácil compreender a origem de determinado aspécto dentro de um código fonte, isso é claramente visível, quando a necessidade da implementação contorna a atual politica de código adotada na solução que se trabalha.

Dessa forma, outros desenvolvedores, podem entender sua intenção implementativa, tornando o código algo mais simples de ser aceitado em outra cultura, por tanto o código limpo, tem uma sintaxe limpa e direta, e normalmente, de boa aceitação para praticamente todas as naturezas de projetos.

Algo importante de se lembrar, que soluções extremamente elegantes, são extremamente problemáticas para cenários desse tipo, imagine implementar sintaxes do C# 7.2 em um código legado de versão 4.0.

A criação da refatoração de códigos arcáicos, quando bem vistos, são uma ótima forma de provar seu estilo de programação para outra cultura, porém, sempre é uma situação de risco manusear códigos de alta responsabilidade para uma outra approach, como migrar funções imperativas para declarativas.

Testable Code and Unit Tests

Outra importânte caracteristica de deffensive codding, é justamente provar que sua cultura de código melhora o que já existe, a melhor forma de fazer isso, é implementar testes unitários em sua solução, visando a minificação de possíveis erros perante o tempo de execução da aplicação.

Ainda frisando a imporância da criação de um padrão de programação viável a testes, é justamente evitar a projeção de bugs possíveis para ambiente de testes humanos, ou no pior dos cenários, no próprio ambiente de produção.

Um código-fonte, que pode ter sua sintaxe testada antes de ser lançado para um ambiente de uso integrado ou contínuo, confirma a boa taxa de manutenção preditiva na solução.

Em outro lado, também torna-se muito legal implementar funções para testes de unidades, compreende-se também dentro desses fatores que é muito interessante dentro da criação de politicas de criação de testes, é isolar unicamente cada função.

Tempo é tudo!

Em uma conclusão rápida, podemos considerar essa approach muito bem vinda em prazos curtos, ou até mesmo em implementações onde seu cliente não dispõe de grande orçamento, isso frisa também que qualquer outro desenvolvedor que consuma objetos de código criados por você, entenda sem dificuldades o que foi feito.

Isso também remete a você como um bom profissional da linguagem de programação, lembre-se disso, acima do valor qualitativo que seu cliente confia em você, esse mesmo ato, vindo de um desenvolvedor, é muito mais belo!