Na matemática, uma solução 'bela' para um problema é simples e elegante. Usa o mínimo de axiomas, premissas e hipóteses possíveis, e pode ser facilmente generalizada para a resolução de diversos outros problemas do mesmo ramo. Evitam-se métodos muito complicados, number crunching etc... os quais são vistos como 'feios' e 'desengonçados'.
Podemos fazer uma analogia para um software bonito - não no aspecto da usabilidade, mas nos aspectos construtivos dele:
- usar o mínimo necessário de bibliotecas;
- ser o mais portátil possível (exceto em situações onde se usam recursos específicos de um sistema operacional);
- ter documentação de qualidade onde ele não for auto-explanatório;
- fugir dos anti-padrões de projeto;
- ser facilmente adaptável para as mais diversas situações.
Como consequência, temos uma ferramenta ou um sistema mais fáceis de manter e de administrar. Torna-se simples modificá-lo para a resolução de diversos problemas, ou aplicá-lo em situações distintas. Eles se tornam mais convidativos para o trabalho em equipe e para o reuso de código.
Nesses aspectos, sinto que muitas das distribuições Linux sofrem de uma falta de elegância: scripts de inicialização pouco amigáveis para quem os edita manualmente, XML atirado para lá e para cá - obviamente prevendo que os arquivos serão editados por outros programas, pacotes fragmentados etc...
O mesmo com outros softwares, são pequenas coisas que conseguem estragar o dia de um sysadmin ou de um usuário mais avançado, como:
- Configurações armazenadas em formato binário (ou XML) e que só podem ser feitas pela interface gráfica.
- Reinvenções contínuas (algumas quadradas) de rodas diversas.
- Excesso de dependências nem tão necessárias (e que no mínimo deveriam ser opcionais).
- Ocultar mensagens de erro para o bem do usuário.
- Entre outras diversas coisas que tornam a aplicação feia.
Da mesma forma, desenvolve-se uma vez e depois simplesmente se usa o trabalho já feito; o tempo gasto em debugging é menor. Facilita-se a portabilidade, e outras pessoas também podem aproveitar aquilo que já foi feito.
É importante notar que simplicidade não necessariamente se traduz em menor número de linhas de código, ou vice-versa: considero ser preferível escrever código um pouco maior, mas mais simples de entender, a usar hacks para economizar algumas poucas linhas de código. Soluções engenhosas são bem-vindas, desde que elas não sacrifiquem as premissas já feitas anteriormente.
Elegância e simplicidade para resolução de problemas não são más ideias: economizam recursos e evitam dor de cabeça para quem precisa ou quer interagir em um nível mais baixo. Podem custar mais na hora de desenvolver a solução, mas a longo prazo, simplificam o trabalho do desenvolvedor, do sysadmin ou de qualquer outro profissional.
E já que eu falei no Arch Linux, é justamente isso tudo que o Jeito Arch (The Arch Way) incorpora. Complexidade sem complicação, código simples e correto, ferramentas compactas e projetadas para interoperar. Arquivos de configuração feitos para serem lidos e entendidos por seres humanos. Tudo aquilo que pode ser considerado fundamental para um software bonito.
Recomendo, por fim, a leitura do excelente Most Software Stinks!, que define princípios gerais para um software bonito.
Nenhum comentário:
Postar um comentário
Não são lidos e não me responsabilizo pelo conteúdo deles.