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

5. Regra da Simplicidade

Projete para simplicidade; adicione complexidade somente aonde necessário.

É muito comum as pessoas acharem que softwares complexos são sinônimos de programadores habilidosos, o que não é verdade, a beleza no desenvolvimento está na capacidade de se manter o código simples e de fácil manutenção, e consequentemente barato.

Muitas vezes a complexidade chega através de requisitos do sistema na forma de solicitações para cumprir tabela, competir com outros sistemas, ou solicitações de um ou pouquíssimos usuários, e na verdade trazem pouca ou nenhuma vantagem para a grande maioria de usuários. Essas são as complexidades desnecessárias, que normalmente fazem com que a manutenção torne-se cada vez mais difícil e consequentemente custosa.

Ignorar a regra da simplicidade gera sistemas complexos e cheios de funcionalidades que a maioria dos cliente não utilizam, aumentando a base de código desnecessariamente.

6. Regra da Parcimônia

Escreva grandes problemas somente quando demonstrado que não há outra saída.

A frase que melhor traduz essa regra é KISS: “Keep It Simple, Sir” (Mantenha Isso Simples, Senhor), ou seja, prolongue, prolongue, aumente a complexidade, somente quando necessário. Sempre que possível reduza grandes problemas em problemas menores, e resolva um de cada vez.

Não ter parcimônia ao desenvolver gera complexidades desnecessárias, a chamada entropia de código. Lembrando que todo código desenvolvido profissionalmente deve ser mantido, e por isso tem um custo, portanto não manter o código simples gera mais custos de manutenção, maior tempo de resposta a bugs e maior dificuldade na curva de aprendizado de novos desenvolvedores.

7. Regra da Transparência

Projete para visibilidade, fazendo análise e depuração mais fáceis.

Facilitar a análise de código significa desenvolver o código de forma a ser facilmente interpretado e analisado. Facilitar a depuração significa desenvolver de forma a ser fácil verificar se o trecho de código está correto, normalmente através de testes unitários.

Quando um código não é desenvolvido para a transparência há poucos ou nenhum log para ser analisado após uma falha. Ou então a interpretação do código é difícil. Sempre que um bug aparece é necessário dispender um grande tempo para entender qual é a causa raiz e como resolver apropriadamente.

8. Regra da Robustez

Robustez é a filha da transparência e da simplicidade.

Um software robusto é um software que funciona bem mesmo em condições adversas que levam ao limite as condições consideradas pelo desenvolvedor.

Seguindo as regras da transparência e da simplicidade a chance de desenvolver um software robusto é muito maior. Seguindo ambas as regras quaisquer falhas detectadas serão facilmente, e rapidamente corrigidas, fazendo com que o sistema torne-se cada vez mais robusto.

Tags: qualidade