Padronização versus robustez

January 30th, 2003 § 3 comments

Como todo esse papo que está rolando recentemente na Web sobre validação de XHTML, HTML e RSS, boas práticas e coisas similares, algumas vezes tem-se um pouco de esperança de que as coisas melhorem do ponto de vista do desenvolvimento. Mas um coisa que freqüentemente é esquecida é que o ser humano é avesso a padronizações. Não classificações, mas padronizações.

Navegando hoje, encontrei uma relíquia dos tempos perdidos da Internet: um e-mail de 1993 por Marc Andreessen, um dos pais do Netscape, respondendo a uma questão de um dos usuários do Mosaic, o navegador em que ele trabalhou antes de criar o Netscape. O usuário criticava o fato do Mosaic aceitar construções inválidas. A resposta de Andreessen foi que as pessoas deveriam parar de reclamar da robustez do mesmo. O usuário ainda pedia que fosse implementada uma função no programa notificando sobre erros na marcação. A isso Andreessen respondeu que sua empresa não tinha tempo, dinheiro ou motivos para fazer tal implementação.

Soa familiar? E de fato, é. Já naquela época, quando os padrões ainda estavam nascendo, era uma qualidade do produto o fato do mesmo ignorar erros e aceitar o que desse e viesse. Isso não representa, necessariamente, um repúdio aos padrões. É simplesmente uma filosofia condizente com a realidade do mercado.

Não estou, claro, dizendo que desenvolvedores não devam se preocupar com a qualidade do que geram. Pelo contrário, o desenvolvedor deve procurar fazer o máximo para produzir a melhor saída possível, qual seja esta.

Um dos princípios de aplicações polidas é que as mesmas são taciturnas sobre os seus problemas pessoais. Elas devem simplesmente lidar com erros sem incomodar os usuários. Programas antendem necessidades do usuário, não o inverso.

Embora esses métodos impliquem em mais trabalho para o desenvolvedor, eles resultam também em mais liberdade e funcionalidade para aqueles que usufruem das ferramentas desenvolvidas. Parece um ponto de vista altruísta, mas não é. Novamente, é uma filosofia condizente com as realidades no mercado. A aplicação mais flexível é a aplicação com mais usuários, e que, conseqüentemente, tem mais mercado.

É claro que qualquer um prefere receber meus dados em XML bem-formado. Mas a menos que o desenvolvedor esteja no controle do ambiente em que as transações se processam — o que, diga-se de passagem, é extremamente incomum — não há outra alternativa a não ser lidar com isso.

E à medida que tecnologias crescem, elas tendem a sair do controle. Uma aplicação rodando em uma rede interna pode escapar de problemas até que seja necessário fazê-la interagir com sistemas de terceiros. E como isso acaba sempre acontecendo, o melhor é não assumir uma entrada perfeita desde o princípio.

Assim, embora padrões sejam necessários eles não devem barrar o desenvolvimento da tecnologia. Não há sentido em fazer progresso tecnológico quando não há resultado para o usuário. O perigo de buscar a perfeição tecnológica é acabar sendo chutado do mercado. Esse foi um dos erros que, ironicamente, a própria Netscape cometeu mais tarde. Jogaram um código terrível e cheio de problemas, mas funcional, por um sonho padronizado que até hoje não se concretizou.

Existe um velho postulado na informática conhecido como Princípio da Robustez, declarado na especificação TCP/IP. Ele diz: “Seja conservador no que você faz, e liberal do que você aceita”.

Em suma, adapte-se. Ou caia fora.

§ 3 Responses to Padronização versus robustez"

  • ventonegro says:

    Sejamos, sim, robustos, mas o desenvolvimento é muito mais rápido e fluido com padrões. Aceitemos entradas inválidas em nossos programas (o que eu não faço), mas depois que o padrão tenha sido totalmente implementado.

    Poucas coisas são mais chatas que a implementação parcial do CSS por parte do Internet Explorer. Um desenvolvedor é incapaz de escrever um layout apenas olhando pros specs do CSS (como já tentei fazer), ele tem que saber quais daqueles seletores e que partes do modelo visual aquele browser implementa. Padrões são bons, porque se fossem aceitos, me permitiriam fazer um único documento para qualquer dispositivo de acesso à Web, seja ele um browser ou um PDA.

  • Ronaldo says:

    Claro! Como eu disse, eu não sou contra padrões. Escrevi a entrada acima reconhecendo as realidades do mercado e as necessidades do usuário.

    Sempre que possível, eu procuro utilizar o que há de mais padronizado para alguma coisa. No trabalho, eu desenvolvo sites que devem rodar somente sob o Internet Explorer. Mesmo assim, procuro fazê-los funcionar também sob o Mozilla (quando há tempo, claro) por causa dos padrões.

    Eu odeio ter que experimentar milhares de hacks para conseguir que minhas stylesheets funcionem nos navegadores mais usados. O meu site principal é implementado em XHTML + CSS2. Foram horas a fio burilando a apresentação para conseguir um resultado uniforme. Mas o resultado é flexibilidade.

    Assim, eu não estava criticando os padrões. Eu estava criticando os que vêem os padrões somente pelos próprios padrões, esquecendo-se do lado humano da tecnologia. Não adiantaria nada fazer o meu site funcionar só no Mozilla e esquecer que metade dos meus acessos vêm do Internet Explorer.

    Em resumo, o alvo é o usuário. A tecnologia, com perdão do trocadilho, é somente periférica.

  • Código aberto e documentação

    Shelley Powers tocou recentemente em um problema extremamente comum em projetos de código aberto: a falta de documentação, seja esta

What's this?

You are currently reading Padronização versus robustez at Superfície Reflexiva.

meta