Mergulhando no Caos

Num mundo onde o jargão e o palavreado vazio são a regra, expressar-se claramente e com objetividade pode ser um tremendo diferencial. Quando todos se esforçam para parecer iguais, ser a exceção garante um lugar de destaque e “Por que as pessoas de negócios…” é um livro que convence a aproveitar-se dessa situação.

O livro é estruturado em quatro partes, cada uma dedicada a uma das armadilhas: obscuridade, anonimato, venda agressiva e tédio. Na maioria das vezes as pessoas querem ser claras, mas o ambiente corporativo que as cerca não é exatamente um meio que as incentiva para isso. Na verdade, o caminho mais natural neste mundinho parece ser exatamente o contrário. Por isso o texto fala de armadilhas, são coisas que nos capturam sem que notemos e das quais ninguém se aproxima de propósito.

Acontece com todo mundo. Tem o gerente que quer parecer mais inteligente que os outros usando algumas palavras difíceis, como “aculturamento”, “objetivar” e “endereçamento”, mas que no fim das contas só deixa de ser compreendido. Qual o problema com “endereço”, afinal?

Tem também o programador sempre ligado na evolução da computação mundo afora que de tanto ler em inglês começa a escrever como se seus textos em português tivessem passado por um tradutor automático dos mais fraquinhos. Parece que o português está ficando obsoleto (ou seria “depreciado”?). O negócio agora é dificultar a compreensão falando portuglês através de expressões como “sistema irresponsivo” ao invés de “sem resposta” ou “comer a própria comida de cachorro” ao invés de “provar do próprio remédio”. Ou até perpetuar traduções tortas como “aplicativo de missão crítica”, que já vem da expressão completamente desprovida de significado “mission critical application” e deveria ser “aplicativo crítico para a missão”.

Muita gente deixa a personalidade em casa quando sai na segunda-feira de manhã e veste um manto de obscuridade disfarçado de profissionalismo junto com a roupa do trabalho. Por causa do ambiente esterilizado da vida corporativa, pensam que precisam deixar aquela pessoa engraçada bem longe e tornarem-se uma versão pausterizada de si mesmos oito horas por dia, cinco dias por semana.

O livro tenta mostrar sempre com muito bom humor quais são as armadilhas mais comuns do discurso corporativo e insiste no argumento de que são exatamente isso: armadilhas. As pessoas não se esforçam para parecer evasivas e vazias de propósito. É bem verdade que às vezes elas querem realmente sair de alguma saia justa, mas isso não acontece todo dia. Portanto, da próxima vez que vir alguém se perdendo com termos esquisitos como “governança” e “missão crítica”, controle a raiva e não ataque ninguém. Ao invés disso, alerte a pessoa para o fato de que talvez os outros não a estejam entendendo muito bem e que talvez seja interessante mudar um pouco o estilo de comunicação.

Por falar nisso, se isso acontecer aqui neste blog, por favor não hesite em avisar. Eu não vou achar que você está sendo implicante nem chato. Prometo.

Parece que Thomas Thurman, um programador envolvido no projeto Metacity, andou falando (ou pelo menos sugerindo) que os astros e estrelas da programação não estão interessados em fazer pequenos consertos. Houve uma discussão interessante sobre esse tema em um dos últimos episódios do LugRadio e os caras citam o Metacity como exemplo de aplicação que não deve parecer muito atrativo para os astros. Para quem não sabe, Metacity é um gerenciador de janelas, um programa responsável, entre outras coisas, por organizar as janelas na tela, decidir onde uma janela vai ser aberta e lidar com redimensionamento e movimentação; ou seja, um programa que quanto mais invisível melhor. Este projeto em particular é tão invisível que nem um website tem. Se você tomar o cuidado de verificar o link que coloquei acima, vai ver que fui obrigado a referenciar um site ftp que contém o código fonte, já que é a referência usada por todo mundo. O raciocínio é que programas de infra-estrutura invisíveis como este não são muito bons para massagear a fama, afinal é difícil ser visto dentro de algo invisível.

Porém programadores não costumam ficar famosos por programar. Então não faz muita diferença se alguém está programando um novo jogo revolucionário ou se dedica seu tempo a escovar bits em um driver para um dispositivo usado por um total de duas pessoas no mundo todo. Eu sei que dizer isso deve ser algum tipo de clichê, mas não posso evitar: programadores famosos não ficaram assim por se preocupar com código, mas por se preocupar com as pessoas.

Isso obviamente não significa que programadores famosos não cuidam do seu código. A maioria deles se preocupa bastante, mas esta não é a razão que os torna admirados por seus pares. Eles conseguem chegar aos pedestais porque tomam o cuidado de compartilhar idéias com os colegas e tornar a indústria toda um lugar melhor para se trabalhar.

Tomemos o Linus Torvalds como exemplo. O cara dispensa qualquer tipo de apresentação, ninguém consegue esquecer o que ele inventou. O que ele escreveu é um núcleo de sistema operacional, algo que, simplificando grosseiramente, só faz se comunicar com o hardware e distribuir tempo de processador e memória para os vários programas que as pessoas querem realmente usar. Ninguém usa o kernel em si, este é só um mal necessário para quem quer rodar programas úteis e é provavelmente o mais longe do usuário final e perto da máquina que se pode chegar. Ninguém nota o kernel trabalhando, assim como ninguém nota o Metacity. As pessoas só notam esses programas quando eles dão pau, se um driver não funciona direito ou se as janelas não querem sair do lugar, por exemplo. O programa do Linus é talvez ainda mais invisível do que o Metacity e mesmo assim ele é um dos programadores mais conhecidos atualmente.

Ele não chegou a este ponto simplesmente por ter escrito um kernel fantástico, mas porque tomou o cuidado de envolver as outras pessoas nisso. Pediu e ofereceu ajuda em listas de discussão, publicou seu código para ser estudado e criticado pelos outros, fez palestras sobre seu modelo de desenvolvimento e até escreveu um livro para contar a história. Ele divulgou uma mensagem e isso fez muita gente crescer junto com ele.

Para alguns exemplos aqui da terrinha vamos considerar primeiro alguns caras que publicam código, como Vitor Pamplona ou o Marcos Tapajós. Da última vez que olhei, o Vitor tinha quatrocentos e vinte e cinco mil, duzentos e noventa e dois projetos publicados como software livre (e o número já deve ter aumentado enquanto eu digitava esta frase). Mas ninguém ia saber quem ele é se não tivesse feito coisas como montar um fórum para reunir a comunidade Java, organizar um blog para escrever textos que ajudassem os outros a se desenvolver e publicar o código dos seus programas para os outros verem. Do mesmo modo, o Tapajós ainda estaria escondido em um buraco em algum lugar se não contribuísse com os outros através de comentários construtivos e se não compartilhasse sua experiência. Eles poderiam gabar-se de como seus programas são maravilhosos em quantas listas de discussão quisessem, se não fizessem nada pelos outros, ninguém iria dar muita atenção.

Não é necessário ter programas famosos para um programador ser respeitado. Um bom exemplo, também brasileiro, é o Vinicius Teles. Ele até andou divulgando um sistema de busca de imóveis misterioso no blog dele, mas acho que ninguém viu ainda o tal sistema até hoje. Também não sei se ele tem algum projeto com o código publicado em algum lugar da Internet. A questão é que eu nem preciso saber. Ele tem o meu respeito — e o de vários outros programadores — porque ajuda seus colegas de alguns outros zilhões de maneiras diferentes como ao publicar entrevistas e até pequenos desabafos em formato de podcast, ao participar em listas de discussão sempre com mensagens detalhadas e esclarecedoras ou até ao organizar conferências das quais não vou poder participar.

Para conseguir reconhecimento e respeito, um programador não precisa só programar muito bem: precisa divulgar seu trabalho. O segredo é que não adianta simplesmente bater no peito e gritar seus feitos aos quatro ventos. Se quiser que alguém o respeite, é preciso ajudar os demais. Ninguém gosta de um sabe-tudo. O crédito que um programador tem dentro de sua comunidade é muito mais uma função do tempo que ele dedica a seus colegas do que do tempo que investe em escrever código.

Um teste é uma verificação feita sobre um programa para garantir que uma determinada entrada produza uma saída esperada. Testes são, de acordo com esta definição (propositalmente vaga), finitos e pontuais. Portanto não podem ser utilizados para verificar completamente a saída de um programa com entradas infinitas. A não ser que se disponha de tempo infinito.

Mas alguém tem tempo infinito?

Como a maioria dos programas úteis têm conjuntos de entrada extremamente grandes (e os infinitos nem são tão raros assim) e tempo não é um recurso muito abundante, testes só podem ser executados para um subconjunto necessariamente pequeno das entradas. Isso limita bastante a efetividade deles como recursos de validação. Não há como verificar se um programa está completamente correto com testes apenas, mas há várias técnicas que podem ser usadas para aproveitar melhor o pouco de certeza que eles podem oferecer. Testes não são perfeitos para validação, mas ainda são a melhor opção disponível.

Para que os testes sejam minimamente úteis, o programa precisa ser escrito com testabilidade em mente. A explosão combinatória pode derrubar os melhores programadores num piscar de olhos. Testar uma função de três parâmetros não costuma ser tão fácil quanto testar duas de dois. Quem quiser escrever testes um pouco menos complicados vai precisar tomar cuidado para não fazer tanta coisa dentro de uma função só. Do mesmo modo é mais fácil testar uma rotina que recebe um parâmetro de um sistema externo como entrada do que uma que faz a chamada internamente.

Estes são exemplos simples de separação de responsabilidades. Talvez sejam até óbvios, mas os defeitos ficam ainda mais destacados quando se está escrevendo o código dos testes junto com o código do programa em si. O maior valor dos testes está aí. Testabilidade é sinônimo de baixo acoplamento, que por sua vez é característica essencial do software bem escrito. Claro que testes servem para verificar corretude, mas somente de código bem feito. Atentar para os testes é mais do que validar saídas para entradas, é garantir que não está escrevendo uma grande bola de código entrelaçada de todos os lados.

Quem costuma acompanhar este blog já deve ter notado que de vez em quando cito Ruby em um exemplo ou outro e às vezes analiso algum aspecto da linguagem. Porém nunca dediquei muito tempo à linguagem, bibliotecas associadas e nem a frameworks interessantes. Nunca escrevi nenhum tutorial, fiz resenha de nenhuma biblioteca nem publiquei novidades sobre Ruby por aqui.

Para estas e outras coisas relacionadas a Ruby vai servir o Minerama. Este novo blog foi uma idéia do João Paulo Lins e estou entrando junto com ele nessa com o objetivo de criar mais um ambiente colaborativo para aprendizado de Ruby (como se já não houvesse milhares). Por “colaborativo” quero dizer que vamos aceitar textos assinados por outros autores. Este é um blog verdadeiramente multi-autor e espero conseguir algumas colaborações bastante interessantes. Por enquanto só há um texto introduzindo os objetivos do projeto, mas não vai demorar para começar a aparecer novidades.

Por fim, não, eu não abandonei nem pretendo abandonar o Mergulhando tão cedo. Apesar de um mês e meio ser um bocado de tempo sem textos novos, pretendo voltar a publicar dentro de uma semana no máximo. Quem preferir pode “ficar no aguardo”, mas fico feliz se você só esperar um pouco. (Notaram como ninguém mais “aguarda” ou “espera”? Todo mundo agora só “fica no aguardo.” Parece que o corporativês vai dominar o mundo mesmo.)

Acabei de ler um dos clássicos da literatura de desenvolvimento de software: The Pragmatic Programmer, de Andy Hunt e Dave Thomas. Os nomes na capa não são esses, mas os caras já são figuras tão carimbadas que todo mundo já conhece os apelidos.

Este livro deve ser um dos maiores culpados pela disseminação — e posterior perda de significado — do termo “pragmático”. A essa altura a palavra já percorreu todo o caminho rumo à terra perdida dos termos de efeito. Talvez a intenção original dos autores tenha sido boa, mas a decisão de usar o termo como um tipo de marca registrada (Pragmatic Press, Pragmatic Unit Testing, etc.) com certeza não ajudou a preservar o significado original.

Não é à toa que o livro é indicado pelos melhores programadores que conheço e virou um clássico moderno. A desvirtuação do termo muito provavelmente foi conseqüência disso: muita gente talentosa comentando e muita gente não tão talentosa assim lendo somente o prefácio. Os capítulos são auto-contidos e parecem muito com textos de blogs (e digo isso como elogio). O estilo é bem informal, gostoso de ler e sempre abarrotado de referências relevantes — tanto internas quanto externas (uma das piores coisas do mundo é gente que só faz referência ao próprio trabalho).

As páginas estão repletas de conselhos sábios de dois dos mais geniais praticantes da arte da programação. Lá pode-se encontrar as práticas óbvias que sempre são ignoradas como usar controle de versão para tudo, preferir formatos de texto puro e dominar um ambiente de linha de comando. Além disso há discussões sobre como organizar equipes, sobre linguagens específicas de domínio e, claro, o mundialmente famoso princípio DRY. Não se vê citações de institutos de pesquisa obscuros para provar nenhum argumento. Ao invés disso, tudo é muito bem argumentado com bastante lógica, sensatez e experiência.

O texto é digerível para os novatos sem se tornar entediante para os veteranos. Às vezes é necessário dar um desconto para o tom fundamentalista do texto (o que é um certo paradoxo para algo com o termo “pragmático” no título), mas em geral a relevância dos conselhos é das mais altas. Este certamente é um daqueles livros que todo programador deveria ler e reler periodicamente.

Há organizações que se esforçam bastante para ter um processo de desenvolvimento de software determinístico e completamente detalhado. O modo mais comum de realizar isso é confeccionar algum tipo de documento eletrônico (um site interno ou algo parecido) especificando todos os procedimentos que os funcionários precisam seguir, que formulários precisam preencher, com quem devem falar e em que momento espera-se que realizem cada uma das atividades. Em muitos desses lugares o Processo é tratado como um verdadeiro tesouro, o recurso mais importante da empresa, por razões um tanto quanto “pragmáticas”. Pelo menos é o que os responsáveis pelo Processo dizem. Ninguém que pretende ser profissionalmente respeitável vai falar que faz algo por intuição ou crendice.

O Processo teoricamente permite que a empresa aproveite as novas contratações com um mínimo de tempo de treinamento e entrosamento. Com um Processo elaborado, quando um novato chega ele só precisa consultar as escrituras, seguir as ordens, conseguir os mais novos modelos de documentos e preencher as lacunas. A idéia é que, se toda a equipe fizer isso e tiver bastante sorte, no fim das contas vão produzir software útil, interessante e barato.

Mas obviamente isto não costuma passar de uma idéia bem intencionada.

Documentos detalhando tudo o que qualquer funcionário possa um dia precisar fazem todo o sentido para organizações em que novatos inexperientes são maioria. Eles podem começar a produzir mais rapidamente do que se esperássemos o tempo necessário para que se adaptassem e evoluíssem. Eles não precisam perder tempo absorvendo a cultura da empresa, porque a cultura oficial já está escrita e devidamente catalogada. Novatos inexperientes também costumam ficar mais exigentes quando começam a se tornar um pouco menos inexperientes. Um processo bem documentado permite trocá-los por sangue novo quando começam a pedir aumentos e benefícios.

O problema com os processos detalhados e rígidos aparece quando a organização quer ter um relacionamento saudável e de respeito com os funcionários, incentivando e premiando o aprendizado ao invés de puní-lo. O Processo serve como aquelas rodinhas para quem está aprendendo a andar de bicicleta. Elas ajudam a não cair, mas nenhum campeão olímpico cogita usá-las. Depois que as pessoas aperfeiçoam suas habilidades e tornam-se capazes de andar sozinhas, aquela parafernália toda só atrapalha. Como já são experientes, sabem instintivamente o que é importante e podem adaptar o processo padrão conforme necessário sob demanda. Eles conseguem eliminar gargalos e otimizar procedimentos sem muita burocracia e muitas vezes sem nem perceber que estão fazendo isso. Gargalos atrapalham o desenrolar dos trabalhos e costumam ser flagrantemente visíveis, as pessoas eliminam alguns deles todos os dias simplesmente porque as incomodam.

Infelizmente fazer isso fica infinitamente mais difícil na presença do Processo, por causa das diversas lacunas a serem preenchidas e dos procedimentos a serem seguidos. Como tudo precisa ser muito bem pensado, definido e aprovado, não sobra espaço para coisas bobas como instinto e melhoria inconsciente. O triste resultado de todo este esforço de formalização é ver pessoas que poderiam se programadores brilhantes se limitando a domar a burocracia. Não adianta se concentrar em ter o formato dos documentos padronizado se o conteúdo não tem valor. Do mesmo modo, não é possível adaptar o formato a um conteúdo de valor se ele é definido previamente e gravado em pedra por alguma entidade externa à equipe. Planos são úteis somente na medida em que ajudam o planejamento, afinal o importante é realizar a atividade, não produzir o documento seguindo à risca o modelo padrão. O importante é o planejamento, não o plano. A atividade, não o sub-produto.

Os lindos modelos, diagramas coloridos e documentos reluzentes servem como muletas de papel feitas para ajudar quem está mal das pernas. Se pensarmos bem, não há nada mais natural para quem não quer confiar no talento das pessoas. Mas para quem quer andar com desenvoltura e desviar dos obstáculos do caminho, muletas só servem para atrapalhar.

Houve muitos comentários interessantes aqui sobre meu último texto e alguns deles falavam em algo chamado “lógica de programação”. Um dos leitores comentou que muita gente se limita a aprender uma nova sintaxe, mas continua usando a mesma lógica para programar (*). Ou seja, continua a pensar do mesmo jeito.

Não há sentido em aprender uma nova linguagem assim.

Não existe “a” lógica de programação, apenas “uma” lógica de programação. Quando escrevi o texto anterior era nisso que eu estava pensando, mas precisei de outras pessoas para me abrir os olhos. O importante é que cada linguagem tem uma forma diferente de interpretar a máquina, uma nova filosofia. O que você vai querer aprender é isso, não a sintaxe simplesmente.

Não há grandes ganhos em aprender C# se você já sabe Java, porque o modelo de pensamento das duas é basicamente o mesmo (e conseguir um exemplo foi bem difícil, já que até mesmo neste caso ainda há o que se aproveitar). Mas a lógica para programar é bem diferente se você usar Haskell no lugar de C. Para quem está acostumado com linguagens em que efeitos colaterais são a regra e não a exceção, aprender Haskell dói. É a dor do cérebro ajustando-se a uma linha de pensamento diferente.

Nem precisamos ir tão longe assim para observarmos a dor. Acontece até mesmo quando se passa de C para C++ (por causa das noções de orientação a objetos) e de Python para Io (por causa da orientação a objetos sem classes). A causa disso tudo é a necessidade de absorver uma lógica diferente. Pensar que existe uma única lógica de programação só vai piorar as coisas. Novas linguagens demoram tanto para se disseminar também porque as pessoas acham que já dominam “lógica de programação” há muito tempo e que só precisam se adaptar a uma sintaxe nova. Elas não querem aceitar a dor.

A moral dessa história já foi escrita por Alan Perlis e citada pelo grande Peter Norvig há muito tempo: “Uma linguagem que não afeta seu modo de pensar sobre programação, não é digna de ser estudada.” A conclusão direta disso é que o que devemos procurar em uma linguagem é um novo modo de pensar, não uma sintaxe nova para o antigo.

* Estas não foram as palavras exatas dele, mas acho que é uma interpretação válida

Muito menos um programador C#, Delphi ou Visual Basic. Para falar a verdade, o que você quer não é nem mesmo um programador Python, Ruby ou Lua.

Este texto também não é um elogio aos programadores Haskell. Você também não vai querer um desses.

Se você tem um problema para ser resolvido com algum programa de computador, o que você precisa é de um programador. Simples assim.

Ninguém precisa da especialização em nenhuma linguagem ou plataforma específica para começo de conversa, mas para programar computadores com certeza você vai precisar de um programador. A verdade é que ele vai precisar de muitas outras habilidades além de proficiência com um compilador, mas se você contratar alguém que não sabe programar, terá uma bela enrascada em mãos. Não importa quantos analisadores de problemas e desenhadores de retângulos sua equipe tiver, se eles não puderem conseguir que um computador faça alguma coisa, seu projeto vai ser um fiasco na certa. A não ser — é claro — que os retângulos possam ser transformados de algum modo em instruções detalhadas executáveis por um computador.

Mas nesse caso você teria programadores. Só aconteceria deles programarem com retângulos, mas ainda assim seriam programadores.

Conhecer uma única linguagem de programação não é um empecilho somente porque muito provavelmente ela não vai mais ser a melhor ferramenta para o trabalho daqui a três ou quatro anos, mas porque mostra uma incapacidade (ou falta de vontade) para aprender. O que nenhum cliente deveria querer são programadores altamente especializados a ponto de conhecer uma única linguagem de programação. Ao invés de um programador especialista na plataforma da moda de hoje, o que você precisa é de um que seja capaz de aprender as de amanhã. O que um bom programador mais precisa, como qualquer bom profissional, não é apenas saber usar as ferramentas do presente, mas ter capacidade de aprender as do futuro.

Não se deixe enganar também por programadores de retângulos, mesmo que eles gostem de ser chamados de modeladores, arquitetos ou de qualquer outro nome que esteja na moda na época. Linguagens visuais também são apenas linguagens. São linguagens que, por serem gráficas, podem parecer independentes de linguagem, mas não deixam de ser linguagens. Não importa que o programador desenhe ao invés de escrever, se ele quis se limitar a desenhar, deve ser porque não quer nem se dar ao trabalho de aprender a escrever.

Especialização em excesso além de tudo cria ilhas muito concentradas de conhecimento. Por algum motivo inexplicável, muitos programadores especializados acham que jogam em times adversários, que estão em trincheiras diferentes e que tudo é uma grande guerra. Se quiser experimentar isso, tente publicar uma notícia que simplesmente cite Ruby (nem precisa ser o tema principal) em um fórum Java e observe o que acontece. O triste é que eles acabam isolando a si mesmos dentro de uma comunidade pequena e perdem de aprender o que as pessoas de fora poderiam ensinar.

O José Oliveira indicou este blog (junto com outros quatro) em um texto publicado como parte da iniciativa BlogDay 2007. Ele não especificou se isto é algum tipo de meme, mas tem todas as características de um. Parece que estou meio atrasado, já que o tal dia foi na última sexta-feira (dia 31), mas vou usar isto como desculpa para indicar cinco blogs que acompanho de qualquer modo (em nenhuma ordem em particular):

Motor curiosidade — Novo blog do Marcos Pereira sobre desenvolvimento de software e essa vida de programador. Promete ser extremamente interessante, a julgar pela qualidade dos dois primeiros textos e pelos textos dele no blog antigo.

Coding Horror — Talvez um dos blogs mais discutidos no pequeno círculo dos programadores. Jeff Atwood costuma abordar com acidez e bom humor assuntos relacionados a tecnologia que vão desde a relevância dos jardins gradeados na internet até como montar uma máquina silenciosa.

Danilo Sato — Para quem quer estar por dentro das últimas novidades em matéria de agilidade e sempre de olho no mundo acadêmico. Danilo costuma freqüentar conferências ágeis (e também algumas não tão ágeis assim) e relata as experiências neste blog, junto com muitos pensamentos úteis.

Thinking Parallel — Mesmo para quem acha que este barulho todo sobre paralelização é só mais uma onda, não custa nada acompanhar o blog do Michael Suess. Apesar dele ser um pós-doutorando, seus textos passam longe do academiquês e costumam ser dos mais digeríveis sobre o assunto.

{ | one, step, back | } — Jim Weirich não é tão conhecido (e forçadamente controverso) quanto David Hansson, mas é uma das figuras mais relevantes quando o assunto é Ruby. Se você programa em Ruby, mesmo que ainda não tenha ouvido falar no cara, já deve ter usado rake ou builder, duas ferramentas criadas por ele.

Qual é a granularidade das modificações que você envia ao seu sistema de controle de versão? Você se limita a modificações pequenas (que mudam o nome de uma varíavel ou outra, por exemplo) ou gosta das mas volumosas (como as que mudam o nome de uma rotina, introduzem um parâmetro novo e ainda corrigem um defeito em um pedaço do código que a chamava)?

Não é uma pergunta retórica. Pode responder. O espaço para comentários ali embaixo serve exatamente para isso.

Quando envio patches para algum projeto, tento torná-los tão pequenos e localizados quanto possível. Eu sei que não é uma experiência muito agradável revisar modificações monstruosas que afetam toda a base de código e tento poupar disso os mantenedores dos projetos para os quais colaboro. Eles são programadores, mas também são gente.

Não é tão raro que uma parte das modificações em um patch sejam aceitas e outras não. Caso o patch enviado seja muito extenso, o mantenedor vai ter um bocado de trabalho para separar as partes boas das ruins. Se ele tiver muitas outras preocupações no dia (o que não é nada incomum), pode ser que ele simplesmente recuse todo o patch, apesar de haver mudanças úteis, só para poupar o trabalho de filtragem. Para quem está contribuindo, certamente é melhor que as modificações sejam aceitas e um conjunto de patches pequenos torna as chances disso acontecer muito maiores do que um único patch grande. Nem todo patch que enviamos é aceito e precisamos conviver com isso. Modificações pequenas e localizadas ajudam muito quando algumas delas precisa ser rejeitadas.

Patches pequenos costumam ser mais ortogonais e fazem muito sentido no contexto colaborativo de um projeto de código aberto, principalmente com sistemas de controle de versão distribuídos. Mas ainda existem sistemas centralizados e — pior — cuja única solução para edição concorrente é usar travas para tentar tornar o desenvolvimento serializado e impedir toda e qualquer tentativa de paralelismo. Como se este cenário não fosse suficientemente ruim, alguns sistemas não suportam commits com múltiplas modificações e obrigam todo mundo a registrar alterações arquivo por arquivo, mesmo que toquem em muitos pontos. Para terminar imagine que a única forma de interação da equipe com a ferramenta de controle de versão seja um cliente gráfico com interface do século passado e dificilmente automatizável.

É serio mesmo, essas coisas ainda existem.

E tem gente que precisa usá-las.

Quando o mundo conspira contra você com tanta intensidade, fica mais difícil resistir à tentação de fazer uma modificação monstruosa com um comentário altamente descritivo como “Modificações do código”. Porém, mesmo quando estou em algum ambiente parecido com este, ainda tento fazer modificações pequenas. Não faço alterações tão pequenas como quando estou usando Darcs e vez ou outra combino duas ou três modificações em uma, mas sempre evito registrar uma alteração que resolva mais de um defeito ou melhoria.

Parece haver um certo conflito entre commits localizados e implementação de recursos. A renomeação de uma rotina, por exemplo, pode ser um dos passos que leva à inclusão de uma nova funcionalidade, mas com certeza não vai resolver a bronca sozinha. As funcionalidades precisam de modificações maiores, mas modificações menores são mais fáceis de entender, revisar e reverter. Será que este conflito real ou apenas um produto da nossa imaginação?