E também porque provavelmente não era uma bagunça.

Por trás desse tipo de bagunça aparente, há sempre uma ordem não óbvia. Para usar um exemplo bastante simples discutido no livro Uma bagunça perfeita de Eric Abrahamson e David H. Freedman (prometo publicar uma resenha apropriada em breve), uma pilha de papéis jogados sobre uma mesa está ordenada por ordem de uso: os mais usados ficam no topo e os menos usados no fundo. Isso acontece naturalmente se você sempre devolver os papéis que precisou da pilha para o topo. Do mesmo modo, se você pedir a alguém para realizar alguma tarefa rotineiramente, as pessoas sem nem perceber acabam bolando procedimentos de modo a facilitar o trabalho, aproveitar melhor o tempo e tornarem-se produtivas. Por isso bons programadores acabam chegando a algo parecido com XP se não forem podados.

Mas este é um blog sobre desenvolvimento de software para programadores e o trabalho do programador é justamente eliminar a bagunça do trabalho das pessoas, escrever programas que as ajudem a se organizar melhor, identificar “processos de negócio” e coisa e tal, certo?

Errado, se o seu ego conseguir aceitar que as pessoas que estão lá fazendo o trabalho no fim das contas sabem muito mais dele do que você.

Muitas vezes o que precisamos não é bem organizar o que as pessoas estão fazendo. Às vezes precisamos somente tornar a bagunça mais eficiente. Quando se tenta organizar muito os processos de trabalho das pessoas a coisa acaba ficando engessada demais. O resultado são sistemas que atrapalham mais do que ajudam e gente que passa mais tempo tentando agradar os sistemas corporativos do que resolvendo problemas dos clientes. Já ouviu a célebre frase “eu entendo, mas o sistema não deixa” quando tentou algo minimamente fora do comum com um banco ou uma operadora de telefone? É disso que estou falando. Resultado dos sistemas paralisantes. Resultado da organização demasiada.

Por outro lado sistemas caóticos terminaram sendo alguns dos exemplos de maior sucesso em nossa indústria. O Unix, por exemplo, é descrito por Martin Fowler como a maior aglomeração de coisas coladas umas nas outras que o mundo já viu. A web, por sua vez, é uma imensa bagunça de documentos, links e referências em escala global. Os dois sistemas têm em comum a filosofia de fazer pouca coisa, mas fazer bem o que escolheram fazer, e permitir que os usuários façam o que bem entenderem utilizando essa fundação. Eles não tentam organizar cada mínimo aspecto da rotina das pessoas. Eles aceitam o fato de que nunca vão conhecer o trabalho das pessoas tão bem quanto elas mesmas e se concentram em permitir que elas tenham liberdade para fazer o que quiserem do jeito que quiserem.

Aí os usuários originais começaram a debandar. Aquela idéia do início já não parecia tão boa. Na verdade parecia uma péssima idéia. A relação sinal-ruído desequilibrou demais para o lado do ruído: mais um caso internético típico da maldição da popularidade.

Mas se a idéia era tão ruim, como conseguiu atrair aqueles geeks no início?

Acontece que a idéia não era ruim. Geeks são muito bons para detectar boas plataformas e foi isso que eles fizeram. Eles começaram a adotar aquela idéia por causa do seu potencial. Não pelo que ela oferecia na época, mas pelo que ela poderia vir a oferecer. Quando as redes sociais falharam em aproveitar esse potencial, eles as abandonaram.

O grande erro dos sites de rede social foi não perceber que o que tinham em mãos era uma plataforma para aplicações, não uma aplicação final. Felizmente isto vem mudando nos últimos anos, com a disponibilização de interfaces de programação para que terceiros hospedem aplicações sobre estes sites e o futuro pode voltar a parecer promissor novamente.

Hoje a maioria das aplicações no Orkut, por exemplo, são basicamente inúteis. Temos desde aplicativos que servem simplesmente para permitir que você use o grafo social para encher o saco de seus amigos até os sites com conteúdo externo que não usam praticamente nada do grafo social mas resolveram subir nesse trem por causa da audiência. Sem contar os mini-aplicativos publicitários sem muita criatividade. Olhando por este lado, o futuro não parece muito alegre. Mas o valor de uma plataforma não está nas aplicações que já foram feitas, mas nas que podem ser feitas.

E o que pode ser feito com essas redes sociais? Ninguém sabe ainda. Se alguém soubesse, já teria sido feito. A questão é que você não pode dizer que esse negócio de rede social não vai pra lugar nenhum só porque ninguém fez nada de interessante ainda. Isso não impede que alguém faça algo no futuro. Se em 1992 você dissesse que a web não iria para lugar nenhum, sua opinião pareceria bastante plausível, mas por volta do ano 2000 teria sido provado o contrário. É bem verdade que as redes sociais podem realmente nunca nos trazer nada de útil, mas isso não pode ser afirmado com base no passado.

A própria web não era muito atrativa na década de 90, mas os geeks viram seu potencial e a transformaram em uma mídia riquíssima. No início não havia aplicações web muito interessantes, mas havia potencial. Se vamos usar as aplicações sobre redes sociais somente para jogar frutas virtuais em nossos amigos ou arranjar algo de útil para fazer é uma decisão que está primeiramente em nossas mãos, desenvolvedores web e geeks em geral. Se conseguirmos construir algo que ajude as pessoas, elas virão.

Tudo bem, deixe-me explicar. Para ficar mais fácil, vamos voltar às bases.

SEO é um acrônimo para Search Engine Optimization que numa tradução bem pé-duro quer dizer Otimização de Engenho de Busca. Aqui já dá pra ver a inconsistência: quem faz otimização dos engenhos de busca são os donos dos engenhos de busca, ora bolas, não os responsáveis pelos sites indexados. Você simplesmente não consegue otimizar algo que você não controla.

Digamos que você escreveu uma rotina para ordenar os valores de uma lista. Como você faz para otimizá-la? Você olha o que pode modificar e reescreve algumas partes de modo a executar mais rápido, consumir menos memória ou algo do tipo, claro. O que definitivamente não conta como otimização da sua rotina é exigir que a entrada sempre venha ordenada de modo que ela não precise fazer nenhum trabalho.

Entretanto, o que se denomina de SEO hoje em dia é basicamente isso, modificar a web para tornar mais fácil para os engenhos de busca acharem o conteúdo. O termo evoluiu para significar Otimização para Engenho de Busca. Muitas vezes é usado como sinônimo para o ato de massagear sites ou páginas de modo a obter uma classificação favorável em relação a alguns termos específicos. Algumas vezes isso inclui até esquemas obscuros de troca de links. O objetivo disso é, no final de tudo, aparecer entre os primeiros resultados quando alguém procurar por algumas palavras relacionadas a seu conteúdo. Chega-se a bolar todo tipo de coisa para conseguir isso, mas a solução definitiva é mais simples do que parece.

Para garantir que sua página vai figurar entre os resultados mais relevantes para um termo de busca basta ter o melhor conteúdo para aquele termo.

Se você tem um site de resenhas de produtos que tem inquestionavelmente a melhor resenha do mundo referente a um produto em particular e alguém procura pelo nome do produto e seu site não aparece em primeiro ou segundo colocado (vamos admitir que o site do fabricante do produto possa ser o primeiro), a falha é dos engenhos de busca, não sua. É o trabalho deles achar o melhor conteúdo. O seu trabalho é ter o melhor conteúdo. Se eles não estão achando o seu conteúdo, simplesmente não estão trabalhando direito.

Não importa como vão fazer para encontrar o melhor conteúdo, eles têm que encontrar. É o que eles se propõem a fazer. É a razão deles existirem. Não importa se eles vão levar em consideração a quantidade de links que cada página recebe em toda a web ou se vão contratar críticos literários para ler e classificar todas as páginas do mundo.

O pessoal do engenho de busca não pode reclamar que você não colocou o nome do produto na URL ou que não incluiu algum tipo de meta-dado para facilitar a indexação. Nada disso importa quando o seu conteúdo é o melhor. Claro que você deve tomar cuidado para tornar o conteúdo fácil de encontrar, garantir que ele vai ser acessível para visitantes usando programas de leitura de tela e certificar-se que o título da página faz sentido. Mas nada disso é SEO, esse tipo de coisa é só Introdução à Web.

SEO no sentido literal só pode ser realizado pelos donos dos engenhos de busca. O melhor meio de fazer SEO como o termo é comumente usado é simplesmente gerar o melhor conteúdo em toda a web. Neste sentido, você não deve perder seu tempo com SEO justamente porque SEO é o que você deveria estar fazendo o tempo todo desde o início.

O objetivo aqui é certamente louvável. Quem não quer uma aplicação fácil de entender? O problema é que este tipo de discurso parte de uma premissa bastante questionável: a de que código é inerentemente difícil de se ler e entender. Estou usando aqui o exemplo dos diagramas, mas o mesmo problema acontece quando se tenta escrever comentários para cada linha de código. Muda o paciente, mas a doença é a mesma.

Digamos que você esteja escrevendo um livro. Você pensou em um bom tema para a estória, delineou vários personagens e conseguiu imaginar até um cenário interessante para o pano de fundo. Mas seus dotes literários não estão muito apurados e o texto começa a ficar meio emaranhado. Você não sabe onde terminar uma cena e começar outra, não sabe onde encaixar os diálogos e qualquer um que começa a ler se perde depois do quarto parágrafo. Apesar disso você tem uma boa estória para contar. O que você faz? Enche o livro de figuras coloridas? Faz um filme para ser distribuído em conjunto?

Claro que não. Você reestrutura a história e reescreve o livro se for preciso. Você não faz uma representação paralela dele em outra mídia, você torna a mídia original mais acessível. Se você não conseguir fazer isso, é melhor procurar outra coisa para fazer. Talvez você possa aprender a escrever melhor se estudar um bocado. Ou talvez você não tenha talento mesmo.

Para o código a solução é a mesma. O texto do programa deve falar por si só, não se deve assumir que há alguma outra representação alternativa para torná-lo mais claro. Se o relacionamento entre as várias partes do código está obscuro, ele deve ser reestruturado de forma a ficar mais claro. Se o nível de detalhamento das rotinas chamadas dentro de um trecho está muito perto do metal bruto, agrupe alguns blocos em rotinas separadas ou crie novo objetos. Faça o que fizer sentido, mas não deixe o código ficar sujo. Assim como todo bom escritor pensa o tempo todo em seus leitores, pense o tempo todo em quem vai ler seu código.

Isso não quer dizer que nunca devamos usar uma representação gráfica ou comentários para explicar código. Voltando à analogia dos livros, ilustrações são coisas legais de se encontrar, só não devem ser partes essenciais do conteúdo. Talvez fique mais fácil entender o que o autor imaginou com elas, mas qualquer bom livro que tenha as ilustrações removidas continuará tão bom quanto antes.

Ninguém dá a mínima para a sua relação teste-para-código.

Nem para sua taxa de cobertura de testes, se é que isso interessa.

A menos que a relação seja zero-para-um, não há absolutamente nada de informativo neste número. A partir do momento em que você está escrevendo algum teste, fazer este número crescer não garante melhoria nenhuma na qualidade do sistema. Talvez você esteja escrevendo testes inúteis para verificar se sua linguagem de programação consegue atribuir um valor a uma variável e recuperá-lo de volta. Talvez você esteja repetindo os mesmos testes o tempo todo. Testar é bom, mas alguns testes são melhores do que outros e este número não é calculado sobre a qualidade dos testes, só a quantidade deles. Não há nenhuma conclusão útil que eu possa tirar do seu número sem dar uma olhada no seu código.

Cobertura de testes é outra métrica bem vazia. Claro que você deve tentar se aproximar tanto quanto possível de 100%, mas a verdade é que chegar a níveis de cobertura acima de 90% não é tão difícil assim. Considere, por exemplo, este trecho de código adaptado do Code Complete do Steve McConnell:

    totalWithholdings = 0;

    for ( id = 0; id < numEmployees; id++) {
        if (m_employee[id].governmentRetirementWithheld < MAX_GOVT_RETIREMENT) {
            governmentRetirement = ComputeGovernmentRetirement(m_employee[id]);
        }

        companyRetirement = 0;

        if (m_employee[id].WantsRetirement &&
            EligibleForRetirement(m_employee[id])) {
            companyRetirement = GetRetirement(m_employee[id]);
        }

        grossPay = ComputeGrossPay(m_employee[id]);

        personalRetirement = 0;
        if (EligibibleForPersonalRetirement(m_employee[id])) {
            personalRetirement = PersonalRetirementContribution(m_employee[id],
                companyRetirement, grossPay);
        }

        withholding = ComputeWithholding(m_employee[id]);
        netPay = grossPay - withholding - companyRetirement -
            governmentRetirement - personalRetirement;

        PayEmployee(m_employee[id], netPay);

        totalWithholdings = totalWithholdings + withholding;
        totalGovernmentRetirement = totalGovernmentRetirement +
            governmentRetirement;
        totalRetirement = totalRetirement + companyRetirement;
    }

    SavePayRecords(totalWithholdings, totalGovernmentRetirement,
        totalRetirement);

É possível obter 100% de cobertura para este trecho completo com apenas um teste: você só precisa garantir que há ao menos um funcionário (para que o loop seja executado) e que as três cláusulas condicionais avaliem para verdadeiro. Obviamente um único teste não é o suficiente para testar todas as nuances deste código e, de fato, McConnel mostra no livro que são necessários pelo menos dezessete testes diferentes. Mesmo assim se tivéssemos escrito aquele único caso de teste, enxergaríamos cobertura total.

Parece que virou moda ultimamente supervalorizar os testes e divulgar estas métricas vazias. No fim das contas elas funcionam como qualquer métrica para software, só dão uma visão bem abstrata do sistema e podem muitas vezes serem enganosas. Não há substituto para uma boa leitura do código.

Tendo dito isso tudo, eu definitivamente não recomendo tentar desenvolver software sem escrever testes automáticos. Já é difícil desenvolver software usando testes, mas é ainda pior sem eles. Só porque você sabe que não é possível provar ausência de defeitos através de testes, não quer dizer que não deva usá-los. Então, por favor, continue escrevendo-os (ou passe a escrever se você não escreve ainda). Só não aja como se eles fossem a última salvação da humanidade. Eles são só a primeira.

Há basicamente duas maneiras de novas tecnologias influenciarem programadores ruins a escreverem software menos ruim. A primeira é tornar as boas práticas extremamente fáceis de modo que simplesmente pareçam o jeito natural de fazer as coisas. A segunda é tomar o caminho contrário e tornar práticas ruins mais difíceis ou feias de se fazer. Pode-se usar algo como vinagre sintático para fazer isso. O problema de tornar práticas não recomendadas mais feias é que os programadores ruins vão escrever o código feio e ignorar completamente a feiúra. Os olhos deles são incapazes de enxergar feiúra em um trecho de código. Se você quiser realmente seguir por este caminho, precisa dar um jeito de proibir por completo as asneiras mais gritantes.

Mas só é possível enxergar as mais gritantes.

Mesmo que você consiga evitar os piores erros, surgirão novas idéias igualmente burras. Você pode tentar bloquear essas também e continuar tentando proteger as pessoas delas mesmas até um certo ponto. Mas infelizmente não é possível proibir um idiota de estragar tudo. Os idiotas precisam estragar tudo. É a natureza deles. É isso que os define. É por isso que eles são chamados de idiotas. Não importa quantas bolas de chumbo você amarre aos pés deles, os verdadeiros idiotas vão arrumar um jeito de fazer besteira. Se sua tecnologia resolver seguir por este caminho, vai precisar proibir tanta coisa e ficar tão limitada que só os tapados serão atraídos. Aqueles que sabem o que estão fazendo simplesmente não aceitam trabalhar acorrentados.

Já que o caminho da proibição não é tão promissor, é melhor explorar a alternativa: tornar o “certo” idioticamente fácil. Desse modo, os bons profissionais serão atraídos pela elegância das soluções e vão começar a falar sobre a sua tecnologia. Com o burburinho todo mundo vai querer dar uma olhada nesse novo negócio de que os caras da moda andam falando tanto. As idéias ruins serão contidas por algum tempo, mas há um efeito indesejável que você não vai conseguir evitar.

Este efeito está intimamente ligado à maldição da popularidade. Mais popularidade significa mais gente e mais gente significa mais gente tapada. Sua tecnologia preferida simplesmente não pode conseguir se tornar popular e só atrair gênios da computação, eles não são muitos. Para ser popular ela vai precisar dos idiotas. E os idiotas têm um talento natural para estragar as coisas, lembra? Se você quiser ter uma tecnologia amplamente difundida, vai precisar aceitar que ela se torne o novo ASP. Não tem jeito.

Isso precisava mudar e meu texto anterior sobre controle de versão parece ter servido como a desculpa perfeita. Surgiram algumas perguntas e observações nos comentários que me parecem ser bem freqüentes e resolvi compilar as perguntas e as respostas em um texto no formato 10-mais. As perguntas estão parafraseadas aqui e não foram necessariamente redigidas assim originalmente.

Vamos às questões:

Como as empresas podem usar sistemas distribuídos e ainda ter controle sobre seu código fonte?

Entendo a suposta necessidade das organizações de manter um controle rígido e centralizado do código-fonte. É bem verdade que muitas vezes elas fazem isso não tanto por necessidade, mas simplesmente por teimosia ou pela boa e velha força do hábito (também conhecida como inércia corporativa), mas admitamos que seja o caso de realmente haver a necessidade de um local central para se chamar de oficial.

Elas poderiam não usar nenhum sistema de controle de versão e ainda ter controle sobre o código. Basta dizer aos programadores que o código só deverá ser considerado pronto quando for enviado para determinado local. Este local pode ser um repositório de controle de versão centralizado, mas também pode ser um site FTP, um compartilhamento de rede qualquer ou um pendrive na mesa do chefe. Não importa.

A centralização do local de publicação oficial não exige a centralização do sistema de versionamento. Se as empresas simplesmente exigissem que as equipes disponibilizassem o código em algum lugar acessível dentro da rede interna, os programadores poderiam escolher qualquer método que quisessem para controlar suas modificações. Eles poderiam transferir arquivos de máquina em máquina ou guardar diffs manualmente, mas eu poderia apostar que a maioria deles optaria por um sistema de controle de versão qualquer. Muitas empresas não deixam a equipe escolher sozinha por preferir investir menos no processo de seleção dos funcionários e simplesmente assumir posteriormente que todos são tapados incapazes de limpar o próprio nariz. Quando todo mundo é idiota, é melhor minimizar os graus de liberdade para evitar que eles acabem colocando o dedo na tomada. É melhor exigir que todo mundo use exatamente os mesmos procedimentos e ferramentas. Mas esta é uma questão para um texto futuro.

Não há nada impedindo que os sistemas distribuídos de hoje sejam usados de forma centralizada. A equipe pode muito bem escolher um local para chamar de central e oficial. Eles podem fazer isso, mas não são obrigados. A questão é que há limitações que os sistemas centralizados têm que os distribuídos não têm. Não manter histórico das alterações das cópias de trabalho locais e exigir acesso de rede para commitar são só duas delas…

Como o controle de patches facilita os merges? Se há conflitos, eles precisam ser tratados independentemente do modelo de controle de versão adotado…

Se duas pessoas estão trabalhando no mesmo trecho de código, os conflitos certamente serão os mesmos não importa qual o sistema de controle de versão que usem. Neste caso, elas provavelmente precisam reestruturar o código para evitar pisar nos pés uma da outra. O controle de patches faz uma diferença maior quando os merges precisam ser feitos periodicamente.

O controle de versão por patches (e aí não estou necessariamente falando de controle distribuído, como mostra o texto anterior) evita que você precise lembrar quais as modificações que você já integrou. Um bom exemplo é quando você está fazendo merges sucessivos, como no caso do branch de desenvolvimento que precisa incorporar as modificações feitas no branch de conserto de bugs. Com controle de patches, você pode derivar uma base de código qualquer, fazer modificações locais e incorporar de tempos em tempos as modificações feitas no código original com muito menos dor de cabeça. Você não precisa se lembrar de que ponto do código original começou, nem até onde foi seu último merge. Desde que possua todas as modificações que o repositório original tem, você está atualizado.

Na média os usuários não querem colaborar. Eles contornam o sistema de controle de versão, compartilham código por outros meios e fazem todo tipo de porcaria.

Mais um argumento a favor dos sistemas distribuídos. Dessa vez não só dos não-seqüenciais, mas dos verdadeiramente distribuídos mesmo. A razão das pessoas estarem compartilhando código fora do controle de versão muitas vezes é o fato do código simplesmente não estar pronto para ser publicado. Ele não pode ir para o repositório central ainda, mas não é por isso que deve deixar de ser compartilhado.

Digamos que estou trabalhando em algum tipo de reestruturação extensiva. Para fazer essa reestruturação, eu preciso deixar alguns testes falhando por algum tempo. Eu sei que, quando terminar, os testes vão voltar a passar, mas precisam ficar quebrados enquanto eu termino. Qualquer reestruturação deste tipo pode ser sub-divida em pequenos objetivos. Portanto, faz sentido registrar alguns marcos parciais. Porém, se o sistema é centralizado, eu não posso fazer isso para não atrapalhar meus colegas. Minha única alternativa passa a ser bifurcar a base de código por algum tempo até que eu consiga terminar a reestruturação. Posso fazer isso por meio de branches ou nem usar o controle de versão e compartilhar código pela rede interna de algum outro modo.

Enquanto estou fazendo essa reestruturação, pode ser que você precise de algumas modificações que eu fiz. É em horas como essas que o pessoal começa a compartilhar código pela rede, fazer merge manual e usar de uma imaginação incrível para contornar as limitações do sistema. Com controle distribuído, cada desenvolvedor tem um ou mais repositórios próprios — essencialmente branches pessoais — que, em termos de recursos de versionamento, não deixam nada a desejar em relação ao repositório central. Se você precisa das minhas alterações, você simplesmente as importa diretamente do meu repositório. Não precisamos usar o repositório central como local de troca se não quisermos. Desse modo só nós dois precisamos lidar com aqueles testes falhando, e não a equipe toda.

Programadores ruins gostam de empurrar mouse e precisam de interfaces gráficas intuitivas. Nem todas equipes são bem capacitadas.

Sobre interface gráficas, este não é um problema inerente à distribuição e pode ser resolvido. Na verdade, eu acredito que já venha sendo resolvido. Eu particularmente não tenho problemas para trabalhar na linha de comando, portanto nem chego a procurar esse tipo de front-end. Então não posso dizer com toda a certeza que este problema não existe, mas provavelmente já deve estar bem perto de ser eliminado.

Interfaces intuitivas certamente beneficiam a todos — aos rock-stars também — e devem ser uma busca constante. Mas se uma equipe é pouco capacitada, pode acreditar que a falta de interfaces gráficas não é o maior dos problemas.

A maioria dos sistemas da velha guarda incrementa algum tipo de contador para identificar cada versão do objeto controlado: o Subversion, por exemplo, gera números de revisão quando há modificações em alguma parte da árvore de diretórios e o CVS associa um identificador seqüencial a cada um dos arquivos controlados. O maior problema do versionamento seqüencial é que simplesmente não controla o que queremos que controle. Saber quantas vezes um item qualquer foi modificado é útil, mas não tão útil quanto saber quais foram as modificações e, ainda melhor, quais as dependências entre elas. Sim, é bastante interessante saber qual o estado final de um trecho de código após um certo número de transformações, mas me interessa muito mais saber o que cada uma dessas modificações faz e tratar as modificações como objeto de trabalho, não os resultados delas.

Mais do que quantas modificações aconteceram desde algum ponto qualquer do tempo, eu preciso saber se a segunda modificação pode ser aplicada sem a primeira, se a terceira é uma inversão da primeira ou se a quinta desfaz algumas coisas que a quarta fez. As respostas para todas estas perguntas são necessárias para a operação mais fundamental do controle de versão: o merge.

Quando o Subversion surgiu, lá pelos idos de 2004, um de seus maiores argumentos era o branch barato. Este com certeza é um bom recurso para se ter, afinal de contas derivações precisam ser criadas o tempo todo. Mas o que queremos mesmo é que o merge seja fácil. O branch é só o começo da história. O merge é o ponto alto do processo, é quando as contribuições dos vários envolvidos são combinadas e passam a (pelo menos tentar) funcionar em conjunto. Há uma palestra em que Linus Torvalds resume isto muito bem em algumas poucas palavras: “branches são completamente inúteis, a não ser que você faça o merge”. Só que o versionamento seqüencial pára no branch e o merge precisa ser feito de forma manual porque o sistema não enxerga as dependências entre as alterações, só sabe qual delas aconteceu antes ou depois. Você pode conseguir ajuda para comparar duas versões do mesmo conteúdo, mas é você quem tem que saber quais devem ser as duas versões para este merge em particular que você quer fazer. A coisa fica ainda mais complicada quando você precisa importar modificações de outro branch periodicamente. Quando, por exemplo, seu projeto tem um branch estável em que só se faz conserto de bugs e outro — ou outros — em que são desenvolvidos novos recursos e que precisa receber as mesmas modificações que o estável para se manter livre de bugs. As pessoas acabam desenvolvendo algumas soluções arcanas para controlar manualmente quais alterações já foram aplicadas a quais linhas de desenvolvimento, coisa que o sistema de controle de versão podia (e deveria) fazer sem precisar de babá.

Os identificadores seqüenciais precisam ser atribuídos por algum tipo de servidor central. Não podem ser determinados por máquinas diferentes para evitar conflitos de nomes e acabam sendo completamente artificiais porque refletem simplesmente a ordem em que o servidor recebeu as alterações. Para a maioria das alterações, a ordem de aplicação pouco importa. E quando ela importa, os sistemas com versionamento seqüencial não costumam ajudar.

A alternativa ao controle seqüencial é o controle de patches (termo que admito estar inventando agora, então não deve ser muito preciso e provavelmente você vai encontrar isto com outro nome por aí). Um sistema de controle de patches associa um identificador a uma modificação, não ao resultado dela como os de controle seqüencial. Uma versão qualquer é simplesmente um acumulado de modificações que, quando combinadas, determinam um resultado final.

Sistemas seqüenciais são necessariamente centralizados. Não há como decidir qual o número para a próxima versão se não houver uma autoridade central para controlar a numeração. Porém, o inverso não é verdadeiro. Isto é, sistemas baseados em controle de patches não precisam ser distribuídos. A maioria dos que encontramos realmente é, mas não precisavam ser. A questão é que eles podem ser muito bem usados como sistemas centralizados, mas já tem tudo que precisam para serem distribuídos e independentes de um servidor central. Então porque se limitar? Além de poderem fazer tudo que os centralizados conseguem, os sistemas distribuídos ainda costumam ser muito mais fáceis de instalar. Se o Atwood tivesse escolhido um deles, não precisaria nem escrever um tutorial de instalação para si próprio. Era só escolher inicializar um diretório qualquer como repositório e começar a versionar o que quisesse. Sem serviços. Sem nomes de usuário. Sem senhas. Sem dores de cabeça com o firewall.

Minha impressão é que o funcionamento dos sistemas distribuídos de hoje é muito mais parecido com o modo como naturalmente pensamos do que o dos centralizados. Quando quisesse combinar duas linhas de trabalho distintas eu deveria apenas dizer a meu sistema que quero combinar as modificações que eu tenho com as que meu colega tem e ele deveria ser capaz de fazer isso sozinho (assumindo que não haja conflitos complicados). Eu não deveria precisar criar marcadores artificiais e manter manualmente um histórico de quais alterações dele eu já tenho. Por que algumas vezes ainda insistimos em usar sistemas centralizados? Há alguma vantagem oculta neles ou o quê?

1. Você tem acesso ao código-fonte do programa que está executando e pode fazer basicamente qualquer coisa com ele;
2. Você pode inclusive modificar o programa, mas se quiser fazer isso precisa distribuí-lo sob os mesmos termos.

O sistema é bem elegante: você pode modificar os programas que recebe e/ou redistribuí-los sem modificação, mas deve oferecer a quem receber o programa de você os mesmos direitos que você recebeu. Isso garante que toda melhoria esteja disponível para todos os interessados e acaba criando comunidades em torno de uma peça de software. Claro que o texto completo da licença é bastante extenso, afinal de contas precisa incluir todo o advoguês para cobrir os casos limite e garantir que ninguém perca nenhum desses direitos no meio do caminho, mas a idéia é basicamente esta.

Porém há um detalhe bastante sutil neste esquema todo. Com a GPL, as pessoas precisam ter acesso ao código-fonte dos programas que estão executando. No caso de programas acessados através de uma interface de rede qualquer quem executa o código é uma máquina remota. Os usuários que acessam a aplicação de outras máquinas numa rede não podem ver o código-fonte e o dono do servidor pode modificar o programa o quanto quiser sem precisar distribuir o código-fonte. Afinal de contas, tecnicamente é só ele e mais ninguém que executa o programa. É completamente legal, por exemplo, que alguém baixe a versão 0.6.10 do Motiro, faça algumas modificações locais e sirva a aplicação para quem quiser usá-la sem ver o código-fonte correspondente.

As aplicações web, como o Motiro, são certamente o exemplo mais óbvio de onde este detalhe pode ser explorado para subverter as intenções iniciais do autor e, como parece que tudo atualmente está indo parar na web, ele ficou bastante evidente. Também é importante notar que é bem possível que o autor realmente quisesse deliberadamente permitir este uso, mas vou deixar esta discussão para outro dia. No caso do autor que quer que todos os usuários possam estudar e contribuir com seu programa, o universo de colaboradores pode ser bastante reduzido se forem considerados usuários apenas os donos dos servidores.

Colocando de uma forma bastante grosseira (e abrindo espaço para quem quiser corrigir), a GPL considera que os usuários são as pessoas que detém as máquinas que executam os programas. Neste sentido, os usuários têm todos os seus direitos, inclusive o acesso ao código-fonte, garantidos. Porém, no caso das aplicações web, as pessoas que realmente usam os sistemas (tipicamente através de seus navegadores) não têm nenhum desses direitos.

Num mundo repleto de processamento distribuído onde a maioria das pessoas não sabe exatamente que computador está efetivamente executando os programas que elas usam, a distinção entre executores e usuários deixa de fazer tanto sentido. A GNU Affero General Public License é uma licença com texto baseado na GPL original (dê uma olhada no texto completo para saber os detalhes, eu não sou advogado) que tenta consertar esta brecha. A história da licença é bem complexa, mas se eu tivesse que resumir, diria que para a AGPL não importa se as pessoas estão executando um programa em um processador local e usando os sistemas através dos seus teclados e monitores ou se acessam um servidor através da Internet; não importa se elas estão executando o programa por conta própria ou se usam do serviço de hospedagem oferecido por outra pessoa, se puderem efetivamente usar um programa, são consideradas usuários e, como tal, devem ter acesso ao código-fonte.

(Uma observação relacionada: consegui permissão dos demais autores do Motiro para mudar a licença de distribuição e hoje publiquei a versão 0.6.11 do programa, agora sob AGPL. Se estiver precisando de um sistema para acompanhamento de projetos, considere usar o Motiro.)

Não precisamos nem discutir o que diabos é orientação a objetos para notar que o termo está perdendo o sentido mais rápido do que um raio. Nenhum dos exemplos citados parecem ofender o meu conceito de orientação a objeto e também não vejo porque feririam o de ninguém. Para ser sincero, desde quando os objetos tornaram-se tão sagrados que não possam ser subvertidos um pouco de vez em quando? Apesar disso já vi este argumento ser usado em todos os três casos.

O ponto aqui não é que orientação a objetos não sirva para nada. Nem que o purismo deva ser evitado. Na verdade, o purismo pode ser bastante útil como ferramenta intelectual. Duvido, por exemplo, que muitos dos recursos interessantes introduzidos em Haskell surgissem se não houvesse um compromisso com a pureza da linguagem em termos de transparência referencial. O grande problema com a orientação a objeto não é o purismo.

É o sucesso.

Com a popularização na última década da orientação a objeto o termo se disseminou. Isso fez mal para ele porque quanto mais gente conhece um termo fracamente definido, maiores as chances de ser desvirtuado ou simplesmente usado sem sentido nenhum. Parece que orientação a objeto acabou virando argumento contra qualquer coisa e, como geralmente ninguém sabe a que definição o falante está se referindo, não sobram muitos contra-argumentos. Nas poucas vezes que uma discussão mais ou menos civilizada é possível, o resistente acaba não se convencendo de verdade. Seria melhor que as pessoas dissessem que não gostaram da idéia, mas “estou sendo apresentado a esta técnica agora, parece diferente de tudo que já vi, estou com medo e não quero avaliar melhor as alternativas” não parece tão profissional. Sobra para a velha e leal orientação a objetos.