Peter Seebach (
unixcomponents@seebs.plethora.net)
Escritor freelance
Maio de 2001
Obtenha um melhor entendimentosobre como reutilizar código com sucesso.
"Aqueles que não entendem o UNIX estão condenados a reinventá-lo, precariamente" -- Henry Spencer
Arquitetos de componentes podem aprender muito sobre importantes princípios de projeto estudando Unix, o estudo dos princípios do Unix podem nos ajudar a perceber os ganhos em velocidade de desenvolvimento e confiabilidade que a arquitetura de componentes promete.
O Unix fornece um belo exemplo de uma arquitetura que atinge muitos dos objetivos da arquitetura de componentes, incluindo portabilidade e reutilização de código. Algums dos seus benefícios chaves incluem:
Se um programa simples não pode ser expressado com simplicidade, algo está errado com seu ambiente. A interface shell do Unix permite que muitos programas simples sejam escritos em uma única linha, e de fato, uma única linha é simples o suficiente para que as pessoas utilizem esta facilidade. A possibilidade de programação ad hoc, que é acessível mesmo a pessoas que não pensam em si mesmas como programadores, é uma das coisas que torna o Unix poderoso.
Sem uma interface genuinamente simples, você não tem programação ad hoc para usuários mais ingênuos. Uma interface simples implica que a estrutua de dados pelo menos parece ser simples, o que nos leva à nossa próxima lição.
Uma das coisas que torna prático desenvolver e testar rapidamente aplicações baseadas na arquitetura de ferramentas Unix é que, em geral, os passos intermediários de um processo podem ser revisados rapida e facilmente por um ser humano. Você não precisa escrever um programa especial para mostrar seus dados em uma forma legível -- assim, há um lugar a menos em que um bug pode se esconder quando você não tem a saída que espera. A cada passo do processo, você pode checar seu trabalho.
Se você precisar fazer algo para seus dados que é óbvio para você, mas você não consegue descobrir como explicar isto a um computador, você pode fazer isto à mão, nos dados "reais". Você não precisa usar um programa especial de tradução para passar de e para um formato legível por humanos.
A lição do uniq e do sort, e do tar e do gzip, é que um componente único e monolítico que resolve seu problema inteiramente é menos útil para você que dois ou três componentes que podem ser combinados de uma forma para resolver seu problema hoje e serem combinados de outra forma para resolver um problema diferente amanhã.
Ao manter cada tarefa logicamente distinta em separado, o Unix encoraja os usuários a experimentarem novas combinações. Enquanto você não pode alterar o código de compressão do WinZip ou do StuffIt sem incorrer em grandes custos, é prático acrescentar um novo algoritmo de compressão a um sistema Unix.
Assim como uma interface simples torna possível para usuários inexperientes escreverem programs shell simples, a interface de programação simples de uma ferramenta Unix torna prático para programadores mais experientes escreverem ferramentas para todas as aplicações que usam. Quanto mais fácil É escrever um novo componente para sua biblioteca, tanto mais componentes você irá encontrar por aí, aguardando para serem usados de novo e de novo.
Uma ferramenta Unix precisa conhecer uma API que trate de redes somente se a função da ferramenta é a de interagir com a rede. De outra forma, esta complexidade não é somente escondida, mas completamente removida do programa. Se você quer usar a rede, use uma das ferramentas que tratam da interação com redes.
O Unix encoraja a reutilização por tornar fácil reutilizar código, e por fornecer uma grande variedade de peças importantes para serem reutilizadas. Um arquitetura de componentes elegante e bonita à qual faltam uma seleção de blocos de construção chaves não irá encorajar a reutilização de código. Um sistema em que você tem menos trabalho ensinando um componente a ordenar que fazer uma interface do mesmo com um módulo de ordenamento é um sistema em que ninguém irá se preocupar em reutilizar os módulos existentes.
Se eu não gosto de alguma das ferramentas padrão do Unix, eu não sou obrigado a usá-la: eu posso acrescentar uma nova. Com o tempo, algumas destas novas ferramentas se tornaram populares o suficiente para serem adotadas em uma ou mais dos vários padrões Unix em que os fabricantes baseiam seus sistemas.
Permitir que os usuários desenvolvam seus próprios utilitários e ferramentas leva a melhores componentes para todos usarem.
O Unix não fornece um mecanismo padrão para verificar se uma nova funcionalidade que você gosta está presente em um sistema um pouco mais velho, e não fornce uma forma de tratar a falta de alguma funcionalidade. Na prática, isto raramente é um problema, o comportamento que você obtém se você não especificar uma nova opção será o de sempre, e a nova ferramenta provavelmente é portável para o novo sistema.
Novamente, mantendo as partes logicamente separadas de uma ferramenta realmente separadas é necessário para que isto seja possível. Se sou editor pode fazer seus próprios cálculos, como você pode atualizar a calculadora dele? No Unix, a calculadora é uma ferramenta separada. Assim, se você trocar para uma calculadora mais esperta ou flexível, o editor sequer percebe (e também não protesta).
Os programadores tem uma tendência a ver uma forte divisão entre componentes utilizados para construir uma aplicação, e aplicações, que são de certa forma produtos finais. O Unix não faz isto. Editores são ferramentas, como qualquer outra ferramenta. A interface de linha de comando é uma ferramenta. Tudo pode ser utilizado como uma ferramenta.
O sistema de correio MH é um exemplo particularmente incrível disto. Ele fornece um conjunto de ferramentas, cada uma das quais trata uma parte do processo de ler, escrever, ordenar, e responder a emails. Como cada ferramenta é separada, e cada ferramenta é projetada para permitir o uso de outras ferramentas, os usuários podem criar seus proórios ambientes de processamento de mail personalizados -- todos bem diferentes, e bem integrados com as capacidades básicas do Sistema Operacional.
"O Unix não foi projetado para impedir que você faça coisas estúpidas, por que isto iria também impedir que você fizesse coisas inteligentes." -- Doug Gwyn
Os utilitários e aplicações Unix não tentam antecipar todas as possíveis necessidades, e eles não devem tentar impedir que você faça alguma coisa que possa ser perigosa. Seu programa pode ser tão útil que sobreviva a você. Mesmo se ele não sobreviver, ele pode provavelmente irá sobreviver seu projeto atual sempre que possível: não tente adivinhar como as pessoas -- ou mesmo você -- poderão querer usar o mesmo no futuro.
Esta lição realimenta o argumento da simplicidade. Tentar evitar conseqüências indesejáveis pode vir a ser um desastre (por exemplo, imagine como seria menos convenientes se programas que usam $EDITOR tentassem garantir que seja sempre um programa interativo).
Quando estiver escrevendo um componente, não tente antecipar todas necessidades, descubra qual é a funcionalidade central, e mantenha o foco nela. Isto não significa que você deve evitar a generalidade quando esta é fácil de acrescentar, mas se é difícil tratar um caso especial, não o trate: outros programas que tratam aquele caso e nada mais irão aparecer, e não irão sobrecarregar seu projeto. O componente resultante será menor, mais rápido, fácil de usar, e será feito em tempo.
Pureza ideológica nunca foi parte do modelo Unix. Existem exceções a cada regra. Não tente antecipar todas. Não tente incluir todas. Pegue um domínio de problema, aponte para tudo que estiver fora do domínio e diga "aqui há dragões". Reconheça que existem casos especiais, mas não tente acomodar todos, ou colocar todos em sua estrutura. Uma estrutura flexível e robusta pode acomodar casos especiais, uma estrutura fraca projetada para tratar tudo sem casos especiais será destruída quando um novo caso especial aparecer.
Tente manter o foco em formatos de entrada e saída mais simples. Coloque os dados em fluxos de dados. E por favor, por favor, faça com que os dados sejam legíveis por humanos. O XML é um grande passo em direção a isto: ele permite que você veja a saída de uma ferramenta que esteja falhando e leia-a diretamente.
Os pipes Unix organizam os dados estruturados entre aplicações de uma forma transparente, que permite bastante flexibilidade para outras aplicações e ferramentasoperarem nestes dados de formas que os projetistas originais sequer anteciparam. Em termos práticos, esta habilidade de redirecionar os dados provavelmente irá economizar esforços de programação mais que as melhores metodologias de código estruturado. O XML é um tremendo exemplo de uma tecnologia que aprendeu eta lição. Uma das razões do crescimento meteórico do XML é que o processamento XML traz flexibilidade e extensibilidade similar ao obtido com os pipes Unix. Ao mesmo tempo, o processamento de XML é projetado para adaptar-se em mais ambientes "mainstream".
O XML completou o círculo com as tecnologias do passado, e traz de volta a idéia de sintetizar dados de modos de processamento independentes. Certamente o XML adotou muitas das lições dos pipes Unix, especialmente com a linguagem XSLT.
Obviamente, nem tudo é Unix. Pior, nem tudo é sequer parecido com o Unix. Estas lições podem ser aplicadas a outros ambientes? Outras tarefas? Outras APIs?
É CLARO que podem!
Mesmo que seja um pouco mais custoso em seu ambiente de preferência, gaste o tempo necessário para separar as partes de um programa. Certifique-se que você está decompono-os da forma mais razoável. Lembre-se que o uniq não ordena sua entrada, certifique-se que você mantém separadas tarefas que sejam separadas. Este princípio irá servir você bem esteja você desenvolvendo ou usando componentes, ou se você está envolvido em outro tipo de processo de desenvolvimento de software.
Mantenha-se atento nas operações fundamentais, construa componentes que forneçam estes serviços e nada mais. E então use-os, regularmente.
Finalmente, sobretudo: divirta-se. O Unix tem sobrevivido mais que qualquer outra coisa, por que ele é um ambiente delicioso de trabalhar. Orgulhe-se sempre de seu trabalho. Não corte cantos (diminuir o domínio de seu problema não é cortar cantos, acabar caindo no tratamento de um domínio que você nunca diminuiu é cortar cantos).
Quando criança, Peter Seebach pensou que "rm" era um nome perfeitamente intuitivo para o comando que "ReMove" um arquivo. Desde então tem sido um defensor incondicional do Unix. Você pode entrar em contato com ele em unixcomponents@seebs.plethora.net.