Joel on Software

Joel on Software   Joel sobre Software

 

Outros artigos de "Joel on Software" em Português

Outros artigos de "Joel on Software" em Inglês

Envie email para o autor (apenas em Inglês)

 

Nada é Simples como Parece


Por Joel Spolsky
Traduzido por Eduardo Scoz
Editado por Carlos Duarte do Nascimento
4 de Março de 2002

Nós temos um pequeno problema de usabilidade no CityDesk.

Eis o problema: você pode importar arquivos da web usando um comando do menu (“Import Web Page”). Também é possível importar arquivos do disco para o CityDesk arrastando-os com o mouse. Mas não existe nenhum comando no menu para importar arquivos do disco. Então, ou as pessoas não descobriam que era possível, ou elas tentavam usar o comando “Import Web Page” para importar do disco, o que não dava certo.

Eu achei que seria fácil resolver isto com um Assistente (“Wizard”) de duas páginas. Resumindo: a primeira página do assistente perguntaria “Onde estão os arquivos que você deseja importar?” Se você escolhesse “disco”, a segunda página iria solicitar um arquivo. Se você selecionasse “web”, iria solicitar uma URL.

Quase comecei a implementar, mas alguma coisa me parou e, ao invés disto, comecei a escrever uma pequena especificação. Aqui está ela, por inteiro: 

Página Um
Onde estão os arquivos que você deseja importar? (Disco/Web)
Pagina Dois (Disco)
Caixa de diálogo “Abrir Arquivo” padrão

Página Dois (Web)
Campo para digitar URL com mini-web-browser

De repente um pensamento me ocorreu: “É possível colocar a caixa Abrir Arquivo padrão do Windows, que normalmente é fornecida isoladamente pelo sistema operacional, dentro de um Assistente?”

Humm.

Eu investiguei. Sim, é possível, mas não é divertido e leva algumas horas para fazer funcionar. Como eu poderia fazer isto não ser um assistente ? Eu reescrevi a especificação:

Dois itens no Menu:
1) Importar Página Web da Internet -> Abre o ‘diálogo de endereço da Web
2) Importar Página Web do Disco -> Abre o diálogo de abertura de arquivos padrão.

Muito melhor. Três minutos de projeto que me economizaram horas de implementação.

Se você já gastou mais de 20 minutos da sua vida escrevendo código, a essas alturas você provavelmente já descobriu uma regra: nada é tão simples quanto parece.

Uma coisa simples como copiar um arquivo pode estar cheia de armadilhas. E se o primeiro argumento for um diretório? E se o segundo argumento for um arquivo? E se um arquivo com o mesmo nome já existir no destino? E se você não tiver permissão de escrita?

E se a cópia falhar no meio? E se o destino ficar em um computador remoto que está disponível, mas que precisa de autenticação para continuar? E se os arquivos forem grandes, o link for lento e você precisar mostrar um indicador de progresso? E se a velocidade de transferência cair para quase zero... quando você desiste e retorna uma mensagem de erro?

Uma boa forma de entrevistar candidatos para trabalhar como testadores de software é lhes dar uma simples operação e pedir que eles enumerem todas as coisas que podem dar errado. Uma pergunta clássica do teste de entrevista da Microsoft: “Como você testa o diálogo de abertura de arquivos padrão?” Um bom testador será capaz de listar várias dezenas de situações estranhas para se testar (“arquivo é apagado por outro usuário entre o tempo que ele é listado na caixa e o tempo que você o seleciona e clica em Abrir”).

Ok, então agora nós temos um axioma: nada é tão simples quanto parece.

Existe um outro axioma na engenharia de software, que é: sempre tente reduzir o risco. Uma parte do risco particularmente importante para se tentar evitar é o risco relacionado aos prazos. O risco nos prazos é ruim porque o seu chefe grita com você, o que torna você infeliz. Se isto não é motivação suficiente para você, a razão econômica destes riscos serem ruins é porque você tomou a decisão de desenvolver uma funcionalidade baseado em informações que diziam que o desenvolvimento poderia demorar uma semana. Agora, que você percebe que ela tomou vinte semanas para terminar, aquela decisão podia até estar errada. Talvez se você soubesse que ela iria levar 20 semanas, você teria feito uma escolha diferente. E quanto mais decisões erradas você toma, maior é a probabilidade daquelas pastas bonitas com o logotipo da sua empresa terminarem no depósito de um liquidatário enquanto o seu ex-CEO resmunga “o pior é que não fomos nem ao menos bem-sucedidos o bastante para sermos mencionados no fuckedcompany.com quando fechamos!”.

A combinação do “nada é tão simples quanto parece” com o “reduza riscos” pode levar a uma só conclusão:

Você tem que projetar as coisas antes de implementá-las.

Desculpe-me desapontar você. Sim, eu sei, você leu livros do Kent Beck e agora você pensa que é razoável não projetar as coisas antes de implementá-las. Desculpe, mas não é razoável. Você não consegue mudar partes do seu código “tão facilmente quanto” você consegue mudar nos documentos do projeto. Pessoas falam isto sempre e é errado: “Nós utilizamos ferramentas de alto nível hoje em dia, como o Java e o XML. Nós podemos mudar coisas em minutos no código. Porque não projetar no código?” Meu amigo, você pode colocar rodas na sua mamãe, mas isto não faz dela um ônibus, e se você pensa que você pode refazer a sua função mal-implementada de cópia de arquivos para torná-la preemptiva ao invés de procedural tão rápido quanto eu escrevo esta sentença, você está profundamente enganado.

De qualquer forma, eu não acho que a Extreme Programming realmente prega que não se deve fazer projeto. Eles apenas dizem “não faça projetos mais que o necessário”, o que é bom. Mas isto não é o que as pessoas ouvem. A maioria dos programadores está procurando desculpas para não fazer um projeto básico antes de implementar funcionalidades. Então eles se prendem na idéia de não se fazer projeto algum como moscas em um pega-moscas. Bzzzzzzt! Esta é uma das mais estranhas formas de preguiça, onde você acaba fazendo mais trabalho do que se você tivesse feito de outro jeito. Eu sou muito preguiçoso para projetar as funcionalidades no papel primeiro, então eu apenas escrevo código, e então ele não está certo, e eu tenho que corrigi-lo, e eu gasto mais tempo que se eu tivesse feito de outra forma. Ou, o que é mais comum: eu escrevo código, e ele não está certo, mas já é muito tarde, e meu produto é inferior e eu gasto até o último minuto criando desculpas porque “tem que ser desta forma”. Isto é negligência e amadorismo.

Quando Linus Torvalds critica o projeto, ele está falando de grandes sistemas, que tem que evoluir, ou eles se transformam em um Multics. Ele não está falando do seu código de copiar arquivos. E quando você considera que ele teve uma visão clara de onde exatamente ele estava indo, não é novidade que  Linus não veja muito valor no projeto. De qualquer forma, Linus é muito mais inteligente que nós, então coisas que funcionam pra ele não funcionam para nós, pessoas normais.

Projetar e implementar de forma incremental é bom. Releases freqüentes também é uma boa idéia (embora para software “na caixa” ou para grandes mercados, deixe os clientes malucos, o que nunca é uma boa idéia– ao invés disso, faça milestones internos freqüentes). Muita formalidade no design é uma perda de tempo – Eu nunca vi um projeto se beneficiar de fluxogramas escabrosos ou de UMLização ou de CRCização ou qualquer outro sabor da moda. E aqueles gigantes sistemas com 10 milhões de linhas de código que Linus estava falando deveriam evoluir, porque humanos realmente não sabem como projetar softwares nessa escala.

Mas quando você se senta para escrever uma função para cópia de arquivos, ou quando se senta para planejar as funcionalidades da próxima versão do seu software, você tem que  projetar. Não deixe as sereias persuadirem você a ir para o outro caminho.



Esse artigo apareceu originalmente em Inglês com o título Nothing is as Simple as it Seems  

Joel Spolsky é o fundador da Fog Creek Software, uma pequena empresa de software na cidade de Nova York. Formou-se na Universidade de Yale, e trabalhou como programador e gerente na Microsoft, na Viacom e no Juno.


O conteúdo dessas páginas reflete exclusivamente a opinião do autor.
Todo o conteúdo Copyright ©1999-2005 Joel Spolsky. Todos os direitos reservados.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky