Regra 7: Elimine casos de falha

regra-7:-elimine-casos-de-falha

Série de artigos sobre o livro As Regras da programação de Chris Zimmerman. O livro trata de 21 regras que ajudam programadores a criarem códigos melhores. Em cada post falo um pouco sobre cada regra do meu ponto de vista trazendo alguns exemplos e opiniões sobre o livro, com o objetivo principal de consolidar e compartilhar o conhecimento.

O quanto estou tornando difícil para os usuários de um recurso ou interface cometerem um erro? Este capítulo sugere que essa deve ser a principal pergunta ao projetar softwares.

A ideia de criar sistemas onde seja impossível cometer erros pode parecer utópica. Afinal, os usuários sempre encontram maneiras inesperadas de provocar falhas. Então, qual é a solução?

Zimmerman propõe que, em vez de aceitarmos falhas como inevitáveis, devemos projetar nossos sistemas de modo que elas raramente — ou nunca — ocorram. Embora essa abordagem pareça simples à primeira vista, sua implementação exige disciplina e um compromisso com boas práticas de programação.

Um dos principais pontos deste capítulo é adotar uma programação “defensiva” — prevenir falhas antes que aconteçam. Em vez de depender de blocos de “try-catch” para tratar erros, devemos evitá-los, validando entradas, assegurando pré-condições e simplificando o código. Essas medidas são cruciais para minimizar estados de erro.

Essa ideia é especialmente relevante em sistemas complexos, onde exceções e falhas aumentam a complexidade, dificultando a manutenção e depuração do código. Zimmerman enfatiza que falhas previsíveis não devem ser tratadas como exceções, mas integradas ao fluxo normal do programa. Dessa forma, o código se torna mais robusto, legível e fácil de manter.

Um ponto essencial na criação de interfaces seguras é detectar erros de uso o quanto antes. No pior cenário, o uso inadequado passa despercebido, levando a uma cascata de falhas na interface. No melhor cenário, o design impede que erros sequer ocorram.

Entretanto, é importante lembrar:

“Um erro comum que cometemos ao tentar projetar algo totalmente infalível é subestimar a ingenuidade de pessoas falíveis.”

Em conclusão, não existe um design perfeito. Podemos impedir que o usuário cometa erros diretos, mas os efeitos colaterais são difíceis de eliminar. Nosso objetivo deve ser criar um design que facilite o uso correto e dificulte que algo dê errado.

Total
0
Shares
Leave a Reply

Your email address will not be published. Required fields are marked *

Previous Post
podcast:-why-quality-professionals-should-consider-kaizen

Podcast: Why Quality Professionals Should Consider Kaizen

Next Post
change-and-adaptability

Change and Adaptability

Related Posts