Hoje a última das quatro partes sobre as bases da filosofia Unix, conforme Eric S. Raymond. E para fechar com chave de ouro cinco regras que vão auxiliar no desenvolvimento de sistemas mais robustos.

13. Regra da Economia

Tempo de programação é caro, conserve-o em detrimento do tempo de processamento.

Mesmo em países em que a mão de obra é subvalorizada, o tempo de programação é caro, sempre compensa investir em processamento que em desenvolvimento.

Portanto é preferível fazer o desenvolvimento com pouca preocupação com performance, e se valer de melhoria contínua para otimizar o código quando e aonde necessário, que se preocupar logo inicialmente com a performance.

Há exceções, quando já se sabe de antemão que serão necessárias melhorias de performance, mas a preocupação deve ser apenas em facilitar a implementação de melhorias, e não de efetivamente implementá-las antes de identificar quais são realmente necessárias.

14. Regra da Geração de Código

Sempre que possível desenvolva ou utilize programas geradores de código.

Geradores de código são a alma dessa regra, e sempre foram extensivamente utilizados no Unix, por exemplo é o duo flex-bison utilizados para gerar parsers e compiladores.

Humanos são muito imaginativos, mas podem cair em falhas simples quando a tarefa é repetitiva. Portanto, se gerar código está se tornando repetitivo, prefira geradores de código, além de reduzir o tempo de desenvolvimento, reduzem o nível de falhas, e aumentam a padronização do código.

15. Regra da Otimização

Utilize protótipos antes de refinar o código. Faça funcionar antes de otimizar.

Retomando a Regra da Economia, utilizar protótipos, focando na funcionalidade básica, e depois na otimização, é sempre mais eficiente. Diversos métodos de desenvolvimento já comprovaram que esta é uma boa prática, por exemplo Scrum, com seu “Release early, release often”, ou ainda o modelo de desenvolvimento protagonizado no software livre, e muito bem ilustrado no livro The Cathedral and the Bazaar.

Não seguir essa regra implica em dispender grande esforço para otimizar trechos de código que não são gargalos. O sistema tem indicadores de performance muito bons, mas a performance geral nunca é satisfatória.

16. Regra da Diversidade

Desconfie de quaisquer alegação do tipo “Uma Única Forma Verdadeira”

Não existe bala de prata. Ao assumir isso o próprio autor declara que as próprias regras não são a única solução para todos os problemas. Sempre serviu muito bem para o desenvolvimento Unix, pode servir para outros desenvolvimentos, mas essa não é a única forma correta para desenvolver.

Grupos que não aceitam soluções alternativas, e que se focam desnecessariamente em tecnologias específicas, sem se abrir a novas tecnologias, normalmente são consequência de não seguir essa regra.

17. Regra da Extensibilidade

Projete pensando no futuro, pois ele pode chegar antes de você perceber.

Tenha em mente que tudo o que foi definido hoje pode mudar amanhã. Principalmente no que diz respeito a volume de dados e performance. Equipamentos podem ser atualizados, volume de dados pode aumentar, capacidade de rede pode ser aumentada, ou diminuída, qualquer premissa pode estar em jogo.

Por conta disso, sempre desenvolva pensando que suas premissas podem ser alteradas, e procure, dentro do possível, adicionar essa possibilidade dentro do seu código.

Procure adicionar número de versão em arquivos de formato, arquivos de configurações com caminhos, limites máximos e mínimos, etc.

Sistemas que não seguem essa regra são difíceis de serem adaptados, normalmente tem muitos valores hard-coded e são custosos para serem portados para novas plataformas.

Tags: qualidade