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)

Em 1982, minha família recebeu o primeiro IBM-PC de Israel. Nós fomos até o depósito e esperamos enquanto o nosso PC estava vindo do porto. De alguma maneira eu convenci meu pai a comprar a versão mais completa, com dois floppy disks, 128K de memória, e tanto uma impressora matricial (para rascunhos rápidos) quanto uma "impressora margarida" Brother "Letter-Quality", que fazia o mesmo barulho que uma me tralhadora só que mais alto, quando estava imprimindo alguma coisa. Eu acho que a gente comprou quase todos os acessórios disponíveis: PC-DOS 1.0, o manual de referência com o código fonte da BIOS por $75, Macro Assembler e o maravilhoso monitor monocromático IBM de 80 colunas e... letras minúsculas! A coisa toda custou por volta de $10.000, incluindo as taxas de importação de Israel, que na época eram absurdas. Extravagante!

Bom, “todo mundo” sabia que BASIC era uma linguagem de criança que requer que você escreva código espaguete e transforma seu cérebro em queijo Camembert. Então nós gastamos $600 para comprar o IBM Pascal, que vinha com 3 disquetes. O primeiro passo da compilação ficava no primeiro disquete, o segundo passo estava no segundo disquete e o linker estava no terceiro disquete. Eu escrevi e compilei um programa simples “hello world” (“olá mundo”). Tempo de compilação: 8 minutos.

Humm. Isso é muito tempo. Eu escrevi um arquivo em lotes para automatizar o processo e reduzi o tempo para 7 minutos e meio. Melhor. Mas quando eu tentei escrever programas maiores, como minha maravilhosa versão de “Othello” que sempre ganhava de mim, eu gastava a maior parte do tempo esperando eles compilarem. “É”, um programador profissional me disse uma vez, “a gente costumava ter uma prancha abdominal no escritório para fazer abdominais enquanto estávamos compilando alguma coisa. Depois de alguns meses como programador, eu tinha um abdômen de ferro.”

Um dia, um programa grã-fino chamado Compas Pascal apareceu da Dinamarca. Philippe Kahn o comprou e o renomeou Borland Turbo Pascal. O Turbo Pascal era meio chocante, basicamente porque ele fazia tudo que o IBM Pascal fazia, só que rodava em 33K de memória, incluindo o editor de texto. Isso não era nada menos que assombroso. Ainda mais assombroso era o fato de que você podia compilar um programa pequeno em menos de um segundo. É como se uma companhia da qual você nunca ouviu falar apresentasse um clone do Buick LeSabre que podia atingir  1.000.000 km por hora e andasse ao redor do mundo com tão pouca gasolina que uma formiga podia tomar sem passar mal.

De repente, eu me tornei muito mais produtivo.

Foi aí que eu aprendi o conceito do loop REP . REP significa “Ler, Avaliar, Imprimir” (do Inglês “Read, Eval, Print”) , e descreve o que um interpretador lisp faz para viver: ele “Lê” os dados que você introduziu, os avalia e imprime o resultado. Um exemplo de loop REP é mostrado abaixo. Eu digito alguma coisa e o interpretador lisp lê, avalia e imprime o resultado.

Em uma escala um pouco maior, quando você está programando, você está em uma versão macro do loop REP chamada “Edit – Compile – Test loop” (loop Edite – Compile - Teste).  Você edita seu código, compila, testa e vê como ele está funcionando.

Uma observação crucial aqui é que você deve percorrer o loop várias vezes para escrever um programa, então quanto mais rápido o loop Edite-Compile-Teste, melhor será sua produtividade, até o limite de compiladores instantâneos. Esta é a razão tradicional, cientificamente falando, porque programadores querem hardware muito rápido e desenvolvedores de compiladores farão qualquer coisa para conseguir loops Edite-Compile-Teste super rápidos. O Visual Basic faz a análise gramatical (“parsing”) e léxica (“lexing”) a cada linha que você digita, para que a compilação final possa ser super rápida. O Visual C++ faz isso oferecendo compilação incremental, cabeçalhos pré-compilados e link incremental.

Mas tão logo você começa a trabalhar em uma equipe maior, com vários desenvolvedores e testadores, você encontra o mesmo loop de novo, só que maior  (é fractal, cara!). Um testador acha um “bug” no código e reporta o “bug”. O programador conserta o “bug”. Quanto tempo demora até que o testador ache outro “bug” na nova versão do código? Em algumas organizações este loop Reporta-Conserta-Testa pode demorar algumas semanas, o que significa que toda a organização está sendo improdutiva. Para manter o processo de desenvolvimento funcionando bem, você deve se concentrar em conseguir que o loop Reporta-Conserta-Testa seja o menor/mais rápido possível.

Uma boa maneira de fazer isso é fazendo compilações diárias. Uma compilação diária é uma compilação automatizada, diária, completa da árvore do código fonte.

Automática – porque você configura o código para ser compilado a uma certa hora, todos os dias, usando “cron jobs” (no UNIX) ou o automatizador de tarefas (no Windows).

Diária – ou até mais freqüente. É tentador fazer compilações contínuas, mas provavelmente você não pode, por causa de problemas de controle de versão do código fonte, sobre os quais eu vou falar em um minuto.

Completa – provavelmente seu código tem várias versões. Versões em diferentes idiomas, diferentes sistemas operacionais ou uma versão completa/compacta. A compilação diária precisa incluir todas elas.  E precisa compilar cada arquivo do início, sem se basear na capacidade incremental, provavelmente imperfeita, do compilador.

Aqui estão alguns dos muitos benefícios de compilações diárias:

1.      Quando um “bug” é consertado, os testadores têm acesso à nova versão rapidamente e podem re-testá-la para ver se o “bug” foi eliminado.

2.      Desenvolvedores sentem-se mais seguros se eles souberem que a mudança que eles fizeram não vai estragar nenhuma das 1024 versões do sistema que é produzida, sem necessariamente ter um computador com OS/2 na mesa para testar nele.

3.      Desenvolvedores que atualizam suas mudanças no repositório pouco antes da compilação diária sabem que não vão atrapalhar todo mundo checando algo que vai “quebrar a compilação” – ou seja, algo que faça com que ninguém consiga compilar o código.  Isso é equivalente a Tela Azul da Morte para toda a equipe de programação, e acontece muito quando um programador esquece de adicionar algum arquivo que ele criou ao repositório. A compilação vai bem na máquina deles, mas quando alguém checa o código, recebem erros de linker e são impedidos de continuar qualquer trabalho.

4.      Grupos externos, como Marketing, clientes beta que precisam usar o produto ainda imaturo, podem escolher uma compilação que é sabida estar razoavelmente estável e usá-la por algum tempo.

5.      Mantendo um arquivo de todas as compilações diárias, quando você descobrir alguma coisa realmente estranha, um novo “bug”, e você não tem a menor idéia do que pode estar causando o problema, você pode usar busca binária (“binary search” ) nos arquivos e apontar exatamente quando o “bug” apareceu pela primeira vez no código. Isto, aliado a um bom controle de versão da fonte, provavelmente fará com que você possa checar qual “check-in” (N. do T. “check-in” significa atualizar a mudança no repositório) causou o problema.

6.      Quando um testador reporta um problema que o programador acha que foi corrigido, o testador pode dizer em qual compilação ele viu o “bug”. O programador pode procurar quando ele implementou a mudança e dizer se o “bug” foi realmente consertado.

Aqui está como fazer isso: você precisa de um servidor de compilação diária, que provavelmente vai ser o computador mais rápido no qual você pode colocar suas mãos. Escreva um “script” que extrai uma cópia completa do código fonte atual do repositório (você está usando controle de versões, não está?) depois compile do início todas as versões do código que você distribui. Se você tiver um programa de instalação ou setup, compile ele também.  Tudo o que você distribui para seus clientes deve ser produzido através do processo de compilação diária. Coloque cada compilação em seu próprio diretório, codificado por datas. Rode o seu script em uma hora fixa do dia.

• É crucial que tudo que for necessário para fazer uma compilação final seja feito pelo script de compilação diária, desde checar o código até colocar os bits em um servidor web no lugar certo para o público fazer download (apesar de que durante o desenvolvimento este servidor será um servidor teste, claro). Este é o único modo de assegurar que não há nada no processo de compilação que seja apenas “documentado” na cabeça de uma pessoa. Você nunca será pego em uma situação na qual você não pode distribuir um produto porque só a Shaniqua sabe como criar um programa de instalação e ela foi atropelada por um ônibus. Na equipe da Juno, a única coisa que você precisavar saber para criar uma versão completa do início era onde o servidor estava e dar um duplo clique no ícone “Compilação Diária”.
• Não há nada pior para sua sanidade mental do que quando você está tentando distribuir o código, e há um bugzinho, então você conserta aquele bugzinho no próprio servidor de compilações diárias e distribui. Como uma regra de ouro: você só deve distribuir código que tenha sido produzido por uma compilação completa e limpa, que começou com uma checagem completa.
• Ajuste seu compilador para o nível máximo de segurança (W4 nos programas da Microsoft; -Wall no mundo do gcc) e para parar se ele encontrar até mesmo a menor advertência ("warning").
• Se uma compilação diária for quebrada, você corre o risco de parar toda a equipe. Pare tudo e continue construindo até que o problema seja eliminado. Alguns dias você pode ter várias compilações diárias.
• O seu “script” de compilação diária deve reportar falhas via e-mail para toda a equipe de desenvolvimento. Não é difícil copiar os avisos de “erro” ou “warning” e incluí-los no e-mail também. O script também pode adicionar relatórios de status para uma página HTML visível para todos, para que programadores e testadores possam rapidamente verificar qual compilação foi bem sucedida.
• Uma regra que nós seguimos na equipe do Microsoft Excel que teve muito sucesso foi quem quer que fosse o responsável por quebrar a compilação se tornava responsável por tomar conta das compilações até que outra pessoa a quebre de novo. Além de servir como um engenhoso incentivo para manter a compilação funcionando, a posição de compilador-mestre era distribuída entre a equipe, então todos aprendiam como as compilações diárias eram feitas.
• Se a sua equipe trabalha no mesmo fuso-horário, uma boa hora para fazer a compilação diária é na hora do almoço. Dessa forma todo mundo poder checar seu código mais recente pouco antes do almoço, a compilação roda enquanto eles estão almoçando e quando eles retornam, se a compilação estiver quebrada, todo mundo está por perto para consertá-la. Tão logo a compilação esteja funcionando de novo, todos podem checar a versão mais recente do código sem medo de ser brecado devido a uma compilação quebrada.
• Se a sua equipe estiver trabalhando em dois fusos diferentes, faça a compilação diária em uma hora em que as pessoas em um fuso não brequem as pessoas em outro fuso. No equipe da Juno, as pessoas em Nova York checavam as coisas as 7 da noite (horário de NY) e iam para casa. Se eles quebrassem a compilação a equipe de Hyderabad, na Índia estava chegando para trabalhar (por volta de 8 da noite no horário de NY) e estavam completamente bloqueados durante todo o dia. Nós começamos a fazer duas compilações diárias, cerca de uma hora antes de cada equipe ir para casa e isso resolveu o problema completamente.

Para ler mais sobre o assunto:

• Algumas discussões sobre ferramentas para compilações diárias
• Fazer compilações diárias é tão importante que é um dos 12 passos para um código melhor.  
• Há muita coisa interessante sobre as compilações (semanais) feitas pela equipe do Windows NT no livro Showstopper, de G. Pascal  Zachary .
• Steve McConnell escreve sobre compilações diárias aqui.