Bom dia povo!
Vemos hoje a quarta parte de “The Cathedral and the Bazaar”. No versículo passado vimos a terceira.
Embora eu não afirme ser um ótimo programador, tento imitar um. Um traço importante dos grandes é a preguiça construtiva. Eles sabem que você recebe um A não por esforço, mas por resultados, e que é quase sempre mais fácil começar com uma boa solução parcial do que por nada.
Confira as Oportunidades e Comece a Investir
Linus Torvalds, por exemplo, não tentou escrever o Linux do zero. Em vez disso, ele começou reutilizando códigos e idéias do Minix, um sistema operacional parecido com o Unix para clones de PC. Eventualmente todo o código do Minix foi embora ou foi completamente reescrito – mas enquanto estava lá, ele forneceu um suporte para o bebê que acabaria se tornando o Linux.
No mesmo espírito, fui procurar um utilitário POP existente que fosse razoavelmente bem codificado, para usar como base de desenvolvimento.
A tradição de compartilhamento de fontes do mundo Unix sempre foi amigável para a reutilização de código (é por isso que o projeto GNU escolheu o Unix como um SO base, apesar de sérias reservas sobre o próprio SO). O mundo do Linux levou essa tradição quase ao seu limite tecnológico; tem terabytes de fontes abertas geralmente disponíveis. Então, gastar tempo procurando por algo mais quase bom o suficiente é mais provável que lhe dê bons resultados no mundo Linux do que em qualquer outro lugar.
E deu pra mim. Com aqueles que eu encontrei anteriormente, minha segunda pesquisa foi composta por um total de nove candidatos – fetchpop, PopTart, get-mail, gwpop, pimp, pop-perl, popc, popmail e upop. O primeiro em que me decidi foi “fetchpop”, de Seung-Hong Oh. Eu coloquei o meu recurso de reescrita de cabeçalho, e fiz várias outras melhorias que o autor aceitou em seu lançamento 1.9.
Algumas semanas depois, porém, me deparei com o código do popclient de Carl Harris e descobri que eu tinha um problema. Embora o fetchpop tivesse algumas boas idéias originais (como o modo background-daemon), ele só poderia lidar com POP3 e era amadoramente codificado (Seung-Hong era naquela época um programador brilhante, mas inexperiente, e ambos os traços apareciam). O código de Carl era melhor, bastante profissional e sólido, mas seu programa carecia de vários recursos fetchpop importantes e bastante complicados de implementar (inclusive os que eu mesmo codificara).
Ficar ou trocar? Se eu mudasse, estaria jogando fora o código que já fiz em troca de uma melhor base de desenvolvimento.
Um motivo prático para mudar foi a presença de suporte a vários protocolos. O POP3 é o mais usado dos protocolos de servidor de correio, mas não o único. Fetchpop e outros competidores não fizeram POP2, RPOP ou APOP, e eu já estava tendo pensamentos vagos de talvez adicionar IMAP (Internet Message Access Protocol, o mais recentemente projetado e mais poderoso protocolo de correios) apenas por diversão.
Mas eu tinha uma razão mais teórica para pensar que mudar também poderia ser uma idéia tão boa quanto, algo que aprendi muito antes do Linux.
- “Planeje jogar um fora; você vai de qualquer maneira.”
– Fred Brooks, The Mythical Man-Month, Capítulo 11
Ou, para colocar de outra forma, muitas vezes você não entende realmente o problema até depois da primeira vez que implementa uma solução. Na segunda vez, talvez você saiba o suficiente para fazer o certo. Então, se você quer acertar, esteja pronto para recomeçar pelo menos uma vez [JB].
Bem (eu disse a mim mesmo) as mudanças no fetchpop foram minha primeira tentativa. Então eu mudei.
Depois que enviei meu primeiro conjunto de patches do popclient para Carl Harris em 25 de junho de 1996, descobri que ele basicamente havia perdido o interesse pelo popclient algum tempo antes. O código estava um pouco empoeirado, com pequenos bugs pendurados. Tive muitas mudanças a fazer e rapidamente concordamos que a coisa lógica a fazer era assumir o programa.
Sem que eu realmente percebesse, o projeto havia escalado. Eu não estava mais apenas contemplando pequenos patches para um cliente POP existente. Eu assumi a manutenção de um inteiro, e havia idéias borbulhando na minha cabeça que eu sabia que provavelmente levaria a grandes mudanças.
Em uma cultura de software que incentiva o compartilhamento de código, esse é um caminho natural para um projeto evoluir. Eu estava agindo com esse princípio:
- Se você tiver a atitude certa, problemas interessantes irão encontrá-lo.
Mas a atitude de Carl Harris era ainda mais importante. Ele entendeu isso
- Quando você perde o interesse em um programa, seu último dever é entregá-lo a um sucessor competente.
Sem ter que discutir isso, Carl e eu sabíamos que tínhamos o objetivo comum de ter a melhor solução que tem. A única questão para qualquer um de nós era se eu poderia estabelecer que eu era um par seguro de mãos. Uma vez que fiz isso, ele agiu com graça e prontidão. Espero que eu faça o mesmo quando chegar a minha vez.
[JB] Em Programing Pearls, o notável aforista da ciência da computação Jon Bentley comenta a observação de Brooks com “Se você planeja jogar um fora, você jogará fora dois”. Ele provavelmente está certo. O ponto da observação de Brooks, e de Bentley, não é apenas que você deve esperar que a primeira tentativa seja errada, é que começar de novo com a ideia certa é geralmente mais eficaz do que tentar salvar uma bagunça.
Fim da 4ª parte. Volto amanhã com a quinta. Abraços!
