Dando continuidade ao último post, hoje vamos conhecer mais quatro, das dezessete, regras das bases da filosofia Unix, conforme Eric S. Raymond em seu livro The Art of Unix Programming.

9. Regra da Representação

Armazene conhecimento na forma de dados, para que a lógica seja burra e robusta.

Análise de código ou algoritmos é um processo tedioso, difícil e sujeito a falhas, ao contrário da análise dos dados. Basta tomar como exemplo um fluxograma, diagramas de estados, ou diagrama de sequência.

Gerir dados é muito mais simples e menos sujeito a falhas que gerenciar código. Ao preferir armazenar conhecimento sob a forma de dados, a manutenção geral do sistema fica muito mais simples e mais barata.

10. Regra da Menor Surpresa

No projeto de interfaces, sempre faça a coisa menos surpreendente.

A melhor interface é tão intuitiva que não necessita de treinamento específico. Ou seja, em um programa de calculadora o + deve efetuar soma, não há necessidade de inventar um novo símbolo.

Mantenha sempre em vista qual é o público alvo. Se o público alvo for engenheiros, por exemplo, é perfeitamente plausível utilizar lógica polonesa reversa (RPN) como interface de uma calculadora, porém se o público alvo for usuários menos técnicos é mais indicado utilizar lógica direta.

Não seguir essa regra vai fazer com que o sistema desenvolvido seja difícil de aprender, e que a maioria dos usuários utilizem um conjunto pequeno de funcionalidades, fazendo com que a maior parte da base de código tenha pouco ou nenhum valor.

11. Regra do Silêncio

Quando não houver nada surpreendente para falar, não fale nada.

“Silêncio é ouro”, já dizia o ditado. Programas silenciosos nasceram no Unix por conta de necessidade, no tempo em que não havia telas e cada caractere deveria ser impresso, mas acabou se mostrando uma ótima prática mesmo depois das telas terem se popularizado.

Isso se dá porque a capacidade do usuário é limitada, e sua atenção não deve ser desperdiçada. E mesmo quando a saída é interpretada e processada por outro programa, simplificar e reduzir é muito bem vindo.

Ignorar a regra do silêncio pode gerar saídas que fornecem tantas informações que as realmente importante acabam misturadas dentre as inúteis, a recuperação e interpretação de informações e de logs fica muito dificultada.

12. Regra do Reparo

Se falhar for inevitável, falhe da maneira mais ruidosa possível.

Sem esquecer a regra da robustez, que diz que um sistema deve ser tolerante a falhas; nem sempre é possível prever tudo o que pode dar errado, e nessa hora o programa tem que falhar.

Quando falhar um programa deve explicar de forma muito clara que falhou, notificando o usuário, e deve armazenar de forma detalhada o motivo da falha, facilitando a solução.

Ao não seguir essa regra teremos sistemas que falham e ninguém fica sabendo, não há uma notificação. Além disso não há anotações apropriadas em logs, arquivos de saída e fica muito difícil determinar o motivo da falha. Por consequência as falhas se repetem e são difíceis de serem corrigidas.

Tags: qualidade