Filosofia de engenharia: Linus Torvalds, o caso especial que desaparece

Pontos principais

• Bom gosto é quando o caso especial desaparece. Reformule a estrutura de dados – um ponteiro para um ponteiro em vez de um ponteiro – e o if que tratava o caso de borda não terá mais onde existir.
• “Me mostre o código” é uma epistemologia, não um slogan. Um projeto é uma hipótese; só o código em execução encerra a discussão.
• O git torna a distribuição uma consequência da sua estrutura de dados. Objetos endereçados por conteúdo significam que todo repositório é igual, então “a única cópia verdadeira” nunca existe para ser defendida.
• Confiança em escala precisa ser estruturada, não presumida. Torvalds resolveu isso duas vezes – uma árvore de mantenedores para quem é responsável, um histórico à prova de adulteração para o que aconteceu.

O princípio

“Quero que você entenda que às vezes dá para enxergar um problema de outra forma e reescrevê-lo de modo que um caso especial desapareça e se torne o caso normal, e isso é bom código.” – Linus Torvalds, TED, 2016¹

Torvalds estava no palco do TED segurando duas funções em C lado a lado. As duas removiam um item de uma lista ligada simples. A primeira percorria a lista com um ponteiro prev, testava se o item a remover era a cabeça e se ramificava: tratava a cabeça como caso especial, todo o resto como caso geral. Dez linhas, um if. A segunda função percorria a lista com um ponteiro para um ponteiro – **indirect – de modo que a cabeça não era de forma alguma uma posição especial. Era apenas a primeira coisa para a qual o ponteiro-para-ponteiro por acaso apontava. Quatro linhas, nenhum if.¹

Menos linhas nunca foi o ponto. A condicional na primeira versão só existia porque o programador modelou a cabeça da lista como diferente do restante da lista. Escolha uma estrutura de dados melhor – um ponteiro para um ponteiro em vez de um ponteiro – e a diferença evapora. O caso de borda nunca foi inerente ao problema; era um artefato de como o problema havia sido representado. Bom gosto, no sentido de Torvalds, é exatamente esse movimento, e é a mesma convicção que faz do bom gosto um sistema técnico e não uma preferência estética: a versão elegante vence não por ser mais bonita, mas por ser mais correta, por ter menos lugares onde ainda pode estar errada.

Esse instinto – eliminar o caso especial para que o caso de borda não tenha onde se esconder – atravessa tudo o que Torvalds construiu. Também explica por que a sua outra frase famosa soa menos como um manifesto e mais como uma instrução: “Conversa é barata. Me mostre o código.”²

Experimente acima: remova um nó do meio e depois remova a cabeça em cada modo. Na “forma óbvia”, a cabeça aciona o ramo if (!prev); no “bom gosto”, a cabeça é apenas mais um elo, e a mesma linha única dá conta dela.

Contexto

Linus Benedict Torvalds nasceu em Helsinque, na Finlândia, em 1969, em uma família de língua sueca. Como estudante de ciência da computação na Universidade de Helsinque, ele usava o Minix, um pequeno sistema operacional similar ao Unix escrito pelo professor holandês Andrew Tanenbaum como ferramenta de ensino. O Minix era instrutivo, mas deliberadamente limitado – Tanenbaum o mantinha simples para que os alunos pudessem ler tudo. Torvalds queria mais do que lhe era permitido ter.

Em 25 de agosto de 1991, ele postou no grupo de notícias Usenet comp.os.minix: “Estou fazendo um sistema operacional (gratuito) (só por hobby, não vai ser grande e profissional como o gnu) para clones AT 386(486).”³ A ressalva entre parênteses é o erro de julgamento mais citado da história do software.

O hobby se tornou, por qualquer métrica de implantação, o kernel mais executado do planeta – ele move a maioria dos servidores web, todo telefone Android e a parcela esmagadora da infraestrutura de nuvem e supercomputação.

A arquitetura foi contestada desde o início. No começo de 1992, Tanenbaum abriu uma thread intitulada “LINUX is obsolete”, argumentando que um kernel monolítico era “um passo gigantesco de volta aos anos 1970” e que os microkernels – em que o sistema operacional é decomposto em serviços isolados que se comunicam por mensagens – eram o futuro.⁴ Torvalds admitiu que os microkernels eram superiores “do ponto de vista teórico e estético”, e então continuou construindo o monolítico porque ele funcionava, era rápido e estava pronto para uso. O debate é lembrado como o documento fundador de um temperamento: a teoria perde para um sistema que funciona.

O trabalho

O kernel do Linux (1991-): um monólito que escalou

O Linux é um kernel monolítico: escalonador, gerenciador de memória, sistemas de arquivos e drivers de dispositivo rodam todos em um único espaço de endereçamento privilegiado. A crítica de Tanenbaum não estava errada em teoria – uma falha em um driver monolítico pode derrubar o sistema de um jeito que um microkernel consegue isolar. A resposta de Torvalds foi empírica. O monólito era mais rápido, mais simples de escrever e podia ser modificado por milhares de colaboradores sem que cada um deles tivesse que aprender antes um protocolo de troca de mensagens. A arquitetura que perdeu a discussão acadêmica venceu a guerra da implantação porque reduziu o custo de contribuir.

O kernel hoje é um dos maiores artefatos de engenharia colaborativa já feitos – dezenas de milhões de linhas, milhares de colaboradores por versão. Nada dessa escala foi projetado de antemão. Ela se acumulou, um patch mesclado de cada vez, sob um modelo de desenvolvimento que Torvalds também teve que inventar.

O modelo de mantenedores: confiança como uma árvore

Torvalds não lê a maior parte do código que entra no Linux. Ele não consegue – o volume está muito além de qualquer pessoa sozinha. Em vez disso, o kernel é governado por uma hierarquia de confiança. Os mantenedores de subsistemas são donos das suas áreas. Eles revisam patches, incorporam-nos às suas árvores e enviam pull requests para cima, aos tenentes e, em última instância, a Torvalds, que mescla as árvores em que confia. Ele é o ditador benevolente na raiz, mas o seu verdadeiro trabalho é curar em quem confia, não auditar cada linha que eles produzem.

A árvore de mantenedores é uma arquitetura social, e ela enfrenta o mesmo problema que toda cadeia de suprimentos de software moderna enfrenta: você não consegue verificar pessoalmente tudo, então a confiança precisa ser estruturada em vez de presumida. É por isso que um repositório não deveria votar na própria confiabilidade e por que o código aberto não é uma fronteira de segurança – os muitos olhos só ajudam se alguém for responsável por olhar. A lista de e-mails, com a sua revisão famosamente direta, é o mecanismo que torna a árvore de confiança legível: decisões e suas justificativas são públicas, arquivadas e atribuíveis.

git (2005): confiança distribuída como uma estrutura de dados

Por anos o kernel foi desenvolvido usando o BitKeeper, um sistema proprietário de controle de versão distribuído cujo fabricante concedeu uso gratuito ao projeto. Em 2005 esse acordo desmoronou em uma disputa de licenciamento, e Torvalds ficou de repente sem uma ferramenta capaz de lidar com o fluxo de trabalho do kernel.⁵ Então ele escreveu uma. O primeiro commit no git foi em 7 de abril de 2005; em cerca de dez dias ele já se hospedava a si mesmo e gerenciava o kernel.⁶

O que faz do git uma expressão do mesmo princípio do exemplo da lista ligada é a sua estrutura de dados central. O git não armazena diffs e reconstrói o estado. Cada versão de cada arquivo, cada árvore de diretórios, cada commit é armazenado como um objeto nomeado pelo hash SHA-1 do seu próprio conteúdo – um armazenamento endereçado por conteúdo. Torvalds é explícito ao dizer que o hashing “nunca foi sobre a segurança. Era sobre encontrar corrupção.”⁶ A identidade é o conteúdo: dois arquivos com os mesmos bytes são automaticamente o mesmo objeto, e um único bit invertido produz um nome diferente e é detectável. E porque “todo repositório é o mesmo e igual”, não existe servidor central privilegiado – o caso especial da “única cópia verdadeira” desaparece da mesma forma que desapareceu o caso especial da “cabeça da lista”.⁶ A distribuição não é um recurso parafusado ao git; é uma consequência de escolher a estrutura de dados certa.

Essa última propriedade – uma cadeia à prova de adulteração de commits endereçados por conteúdo – é a razão de o grafo de commits poder carregar significado além do código, e por que eu penso na sessão como a mensagem de commit: o histórico é o artefato, não um subproduto dele.

O método

O método de Torvalds é o pragmatismo imposto pela evidência. “Conversa é barata. Me mostre o código” foi uma resposta literal na lista de e-mails do kernel a alguém que descrevia o que o seu patch faria.² Um projeto é uma hipótese; o patch é o experimento. Até o código existir e rodar, a discussão segue em aberto.

Por baixo disso está a sua afirmação mais precisa sobre onde de fato reside o discernimento de engenharia: “Programadores ruins se preocupam com o código. Bons programadores se preocupam com as estruturas de dados e suas relações.”⁷ O exemplo da lista ligada é essa frase tornada concreta. Se a estrutura de dados está certa, o código que opera sobre ela é curto e tem poucos ramos, porque a estrutura já absorveu a complexidade. Se a estrutura de dados está errada, você paga por isso para sempre em casos especiais – em instruções if que existem apenas para encobrir um modelo ruim. Preocupar-se com o código é tratar sintomas. Preocupar-se com a estrutura de dados é a cura.

O método de governança combina com o método técnico. O modelo de ditador-benevolente-e-tenentes existe menos para concentrar ego do que para manter a decisão de merge responsável perante um único gosto, ao mesmo tempo em que distribui o trabalho de revisão entre as pessoas mais próximas de cada subsistema. E a franqueza da sua revisão de código – que, por sua própria admissão posterior, às vezes resvalou para uma dureza desnecessária – vem da mesma raiz: o código é julgado por estar certo, não por quem o escreveu ou quanto esforço ele representa. O padrão é impessoal mesmo quando a entrega não foi.

Cadeia de influência

Quem o moldou

Andrew Tanenbaum e o Minix. O Minix foi o sistema operacional com que Torvalds aprendeu e a coisa que ele tentava superar. Tanenbaum lhe deu um sistema similar ao Unix legível para estudar e, através do debate “LINUX is obsolete”, um contraponto afiado o bastante para esclarecer exatamente o que Torvalds valorizava: um sistema que está pronto para uso acima de uma arquitetura que satisfaz. (Influência formadora)⁴

O Unix e as ferramentas GNU. O Linux é um Unix em linhagem de design – processos, arquivos, pipes, a abstração de tudo-é-um-arquivo. E ele só foi útil porque o compilador, o shell e os utilitários do projeto GNU já existiam para rodar em cima dele; Torvalds portou o bash e o gcc antes que o kernel pudesse fazer grande coisa.³ Ele construiu a única peça que faltava – o kernel – e deixou as peças existentes fazerem o resto. Construa o que você precisa; reaproveite o que funciona. (Influência direta)

Quem ele moldou

Todo o mundo do código aberto. O Linux provou que um híbrido globalmente distribuído de voluntários e empresas podia superar em engenharia equipes proprietárias na maior das escalas, e o modelo de mantenedores se tornou o modelo de referência para como grandes projetos abertos são conduzidos.

Todo sistema de controle de versão distribuído depois dele. O git não apenas venceu – ele se tornou o substrato. GitHub, GitLab e o moderno fluxo de trabalho de pull request são todos construídos sobre o modelo distribuído e endereçado por conteúdo que Torvalds escolheu naqueles dez dias. A estrutura de dados sobreviveu à emergência que a originou.

O fio condutor

John Carmack e Torvalds chegam ao mesmo lugar a partir de especialidades opostas. Carmack espreme um problema até que o algoritmo e o hardware se encaixem sem nada desperdiçado; Torvalds reformula um problema até que a estrutura de dados faça o caso especial sumir. Ambos tratam desempenho e elegância como a mesma propriedade vista de lados diferentes, e ambos se recusam a deixar a teoria se sobrepor a uma coisa que comprovadamente funciona. Bom gosto, ao longo desta série, nunca significa decoração; significa uma correção que você consegue sentir. (Ponte da série)

O que eu tiro disto

A lição da lista ligada é a que eu invoco com mais frequência. Quando o código brota um if para tratar “o primeiro” ou “o caso vazio” ou “o usuário admin”, esse ramo costuma ser uma confissão de que o modelo de dados está ligeiramente errado. A correção raramente é um if melhor. É uma representação melhor, depois da qual o ramo deixa de ser necessário porque o caso contra o qual ele protegia não pode mais ocorrer. Essa é a defesa mais barata possível: um caso de borda que não pode existir não precisa de código algum para tratá-lo.

A segunda lição é sobre confiança em escala, e é a que mais importa no mundo em que eu construo agora – sistemas de agentes, em que você orquestra um trabalho que não escreveu linha por linha. Torvalds resolveu o mesmo problema duas vezes: socialmente, com uma árvore de mantenedores que estrutura quem é responsável, e tecnicamente, com o histórico endereçado por conteúdo do git que torna o que aconteceu à prova de adulteração. Você não consegue ler tudo o que um agente produz, assim como Torvalds não consegue ler cada patch do kernel. Então você faz o que ele fez – tornar a confiança estrutural e tornar o histórico verificável – que é exatamente por que eu trato o bom gosto como infraestrutura e a cadeia de suprimentos como a superfície de ataque. A disciplina que construiu um kernel a partir de um hobby é a mesma disciplina que permite a uma base de código acelerar em vez de degradar: acerte a estrutura, e os casos especiais param de se multiplicar.

Perguntas frequentes

Qual é a definição de “bom gosto” no código segundo Linus Torvalds?

Em sua entrevista ao TED de 2016, Torvalds definiu bom gosto usando duas implementações da remoção de um item de uma lista ligada. A versão que ele chamou de sem gosto usava uma instrução if para tratar como caso especial a remoção da cabeça da lista; a versão que ele chamou de bom código usava um ponteiro-para-ponteiro de modo que a cabeça deixava de ser um caso especial por completo. O seu resumo: “às vezes dá para enxergar um problema de outra forma e reescrevê-lo de modo que um caso especial desapareça e se torne o caso normal, e isso é bom código.”¹

O que Linus Torvalds criou?

Torvalds criou o kernel do Linux, que ele anunciou pela primeira vez no grupo de notícias comp.os.minix em 25 de agosto de 1991, e que hoje é o kernel de sistema operacional mais implantado do mundo. Em 2005 ele também criou o git, o sistema de controle de versão distribuído, depois que o projeto Linux perdeu o acesso à ferramenta proprietária BitKeeper. Ele continua sendo o mantenedor principal do kernel do Linux.³⁵

Por que Linus Torvalds construiu o git, e quanto tempo levou?

O projeto Linux havia usado o BitKeeper, um sistema proprietário de controle de versão distribuído, até que uma disputa de licenciamento em 2005 encerrou o acesso gratuito do projeto. Torvalds escreveu o git como substituto, com o primeiro commit em 7 de abril de 2005 e a ferramenta gerenciando o kernel em cerca de dez dias – embora ele observe que havia passado meses antes pensando no design.⁵⁶

O que significa “Conversa é barata. Me mostre o código.”?

Torvalds postou a frase na lista de e-mails do kernel do Linux em 25 de agosto de 2000, como resposta direta a uma discussão sobre o que certo código faria.² Ela captura o seu pragmatismo: a descrição de uma abordagem é apenas uma hipótese, e a discussão não se encerra até que exista código funcional que possa ser executado e testado. (Observação: a frase relacionada “com olhos suficientes, todos os bugs são superficiais” é a Lei de Linus, tal como formulada por Eric Raymond, e não uma citação do próprio Torvalds.⁸)

Fontes