DEV Community

Fernanda Leite
Fernanda Leite

Posted on

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.

Image of Timescale

🚀 pgai Vectorizer: SQLAlchemy and LiteLLM Make Vector Search Simple

We built pgai Vectorizer to simplify embedding management for AI applications—without needing a separate database or complex infrastructure. Since launch, developers have created over 3,000 vectorizers on Timescale Cloud, with many more self-hosted.

Read more →

Top comments (0)

Image of Docusign

🛠️ Bring your solution into Docusign. Reach over 1.6M customers.

Docusign is now extensible. Overcome challenges with disconnected products and inaccessible data by bringing your solutions into Docusign and publishing to 1.6M customers in the App Center.

Learn more