Joel on Software   Joel sobre Software

Outros artigos de "Joel on Software" em Português

Outros artigos de "Joel On Software" em Inglês

Escreva ao autor(Apenas em Inglês)

Em 1982, a minha família recebeu o primeiro dos primeiros PC IBM em Israel. Nós fomos inclusivamente ao armazém e esperamos enquanto o nosso PC era entregue do porto. De alguma forma, convenci o meu pai a comprar a versão mais completa, com duas drives de disquetes, memória 128 K e um conjunto de duas impressoras, uma de matriz de agulhas (para rascunhos rápidos) e uma impressora Brother Letter-Quality Daisy Wheel, que soa exactamente como uma metralhadora quando está a imprimir, apenas que com mais barulho. Acho que obtivemos quase todos os acessórios disponíveis: PC-DOS 1.0, o manual de referência técnico no valor de $75 com a listagem completa do código fonte do BIOS, Macro Assembler, e o extraordinário monitor IBM Monochrome com todas as 80 colunas e ... letras minúsculas! Tudo custou cerca de $10,000 incluíndo as ridículas taxas de importação de Israel na altura. Extravagante!

Agora, "todos" sabem que BASIC era uma linguagem para crianças que requer que você escreva código tipo spaghetti e converte o seu cérebro num queijo Camembert. Pagámos então $600 pelo IBM Pascal que veio num conjunto de três disquetes. O primeiro passe do compilador estava na primeira disquete, o segundo estava na segunda e o linker estava na terceira disquete. Escrevi um simples programa de "olá mundo" e compilei-o. O tempo total de compilação: 8 minutos.

Hmm. É muito tempo. Escrevi um ficheiro batch para automatizar o processo e consegui encurtar a duração para 7 minutos e meio. Melhorou. Mas quando eu tentei escrever longos programas como a minha espectacular versão do Othello que me ganhava sempre, acabava por gastar a maior parte do tempo a esperar pelas compilações. "Yep," um programador profissional disse-me, "nós costumávamos ter uma máquina de abdominais e costumávamos fazer abdominais enquanto fazíamos compilacões. Passados alguns meses de programação eu tinha abdominais espectaculares."

Um dia, um pequeno programa chamado Compas Pascal apareceu vindo da Dinamarca, que Philippe Kahn comprou e renomeou Borland Turbo Pascal. Turbo Pascal era a modos que chocante, visto que basicamente fazia tudo o que o IBM Pascal fazia, apenas que corria em cerca de 33K de memória incluindo o editor de texto. Isto ainda não era o mais impressionante. O mais impressionante era o facto de que você podia compilar um pequeno programa em menos de um segundo. Era como se a empresa que você nunca tinha ouvido falar tinha introduzido um clone do Buick LeSabre que podia atingir 1,000,000 Km/h e andar à volta da Terra com tão pouco gasolina que uma formiga a podia beber sem ficar doente.

De repente, fiquei muito mais produtivo.

Foi quando eu aprendi o conceito de ciclo REP. REP significa "Read, Eval, Print", e descreve o que um interpretador de lisp faz para funcionar: "lê" o seu input, avalia-o, e imprime o resultado. Um exemplo de um ciclo REP é mostrado em baixo: eu escrevo algo, e o interpretador lê, avalia, e imprime o resultado.

Numa escala maior, quando você está a escrever código, você está numa versão macro do ciclo REP chamada ciclo Editar-Compilar-Testar. Você edita o seu código, compila-o, testa-o e vê o quanto ele funciona bem.

Uma observação crucial é que você tem de passar pelo ciclo vezes sem conta para escrever um programa, e assim segue a ideia de que quanto mais rápido for o ciclo Editar-Compilar-Testar mais produtivo você será chegando ao limite natural de compilações instantâneas. Esta é a razão, formal, "informaticamente falando " porque os programadores querem mesmo hardware realmente rápido e programadores de compiladores farão qualquer coisa para ter o super-rápido ciclo de Editar-Compilar-Testar. O Visual Basic faz isso através de análise gramatical e de léxico conforme você vai escrevendo cada linha de código, fazendo com que a compilação final seja bastante rápida. Visual C++ faz o mesmo fornecendo compilações incrementais, headers pré-compiladas e "linkagem" incremental.

Mas assim que você começa a trabalhar numa equipa maior com vários programadores e testadores, você encontra o mesmo ciclo novamente, só que maior. Um testador encontra um erro no código e relata o bug. O programador corrige o erro. Quanto tempo leva até que o testador receba a versão do código corrigido? Nalgumas organizações de desenvolvimento de software este ciclo Relata-Corrige-Retesta pode demorar algumas semanas, o que significa que toda a organização está a funcionar de forma não produtiva. Para manter todo o processo de desenvolvimento a funcionar suavemente você precisa de se esforçar em obter um ciclo Relata-Corrige-Retesta curto.

Uma boa maneira de fazer isto é através das compilações diárias. Uma compilação diária é uma compilação completa, diária, automática de todo o código.

Automática - porque você prepara o código para ser compilado a uma determinada hora todos os dias, através da utilização de processos cron (no UNIX) ou através do serviço scheduler (no Windows)

Diária - ou ainda mais que isso. É tentador fazer compilações continuas mas você provavelmente não pode por causa de problemas com o controlo de versões de código sobre as quais falarei mais tarde.

Completa - certamente que o seu código tem várias versões. Versões múltiplas em várias linguagens, vários sistemas operativos ou a versão topo de gama e uma de baixo de gama. A compilação diária deve compilá-las todas. E precisa de fazer a compilação de cada ficheiro a partir do zero sem se apoiar nas capacidades possivelmente imperfeitas do compilador de recompilação incremental.

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

1. Quando um erro é corrigido, os testadores obtêm a nova versão rapidamente e podem voltar a testar se o erro foi realmente corrigido.
2. Os programadores vão sentir-se mais seguros se uma modificação que fizeram não fizer falhar nenhuma das 1024 versões do sistema que estão a produzir, sem terem efectivamente um computador com o OS/2 na secretária.
3. Os programadores que fazem o check in das modificações imediatamente antes da compilação diária ser iniciada sabem que não vão prejudicar ninguém só pelo facto de checking in algo que faz a "compilação falhar" -- isto é, algo que faz com que mais ninguém consiga compilar. Isto é o equivalente ao Blue Screen of Death para uma equipa completa de desenvolvimento, e acontece muito quando um programador se esquece de adicionar um novo ficheiro que acabou de criar ao repositório de código. A compilação funciona bem no computador dele, mas quando alguém faz o check out, recebem erros de linkagem e são impedidos de continuar a trabalhar.
4. Outras áreas da empresa, como por exemplo marketing, clientes com versões beta, e outros que precisem do produto imaturo podem receber uma compilação que é razoavelmente estável e podem usá-la durante algum tempo.
5. Através da construção de um arquivo das compilações diárias, quando você descobre um erro novo bastante estranho e não sabe qual é a causa, pode usar uma procura binária no historial do arquivo para apontar com precisão quando o erro apareceu pela primeira vez no código. Combinando isto com um bom sistema de controlo de versões de código você pode provavelmente encontrar o check in que provocou o problema.
6. Quando um testador encontra um erro que um programador pensa que está corrigido, o testador pode dizer qual a compilação que contém o erro. Então o programador pode ver quando ele fez o check in da correcção para o erro e ver se ele está mesmo corrigido.

Aqui tem como as fazer. Você vai precisar de um servidor para as compilações, que deve ser provavelmente o computador mais rápido que conseguir arranjar. Escreva um script que faz o check out de uma cópia completa do código que se encontra no repositório (você está a utilizar controlo de versões de código, não está?) e depois compila desde o zero cada versão de código que você vende. Se você tem um "installer" ou programa de setup, compile esse também. Tudo o que você entrega aos clientes deve ser produzido no processo de compilação diário. Coloque cada compilação na sua própria directoria, codificada por datas. Execute o seu script a uma hora fixa do dia.

• É crucial que tudo o que é necessário para fazer a compilação final seja feito pelo script de compilação diária, desde o check out do código até à inclusão da disponibilização do resultado final num servidor de web para o público fazer o download (de notar que durante o desenvolvimento este será um servidor de teste, claro). Esta é a única maneira de assegurar que não vai haver nada acerca do processo de compilação que está apenas "documentado" na cabeça de uma pessoa. Você assim nunca se vai encontrar numa situação onde não pode fazer o lançamento de um produto porque apenas o Shaniqua sabe como criar o "installer", e ele teria sido atropelado por um autocarro. Na equipa Juno, a única coisa que você precisava de saber para fazer uma compilação completa desde o zero era saber onde o servidor estava, e como fazer o duplo click no icon "Compilação Diária".
• Não há nada pior para a sua saúde mental do que quando está a tentar lançar o código, e existe um bug pequenino, que você decide corrigir ali no servidor das compilações diárias e faz o lançamento. Como regra de ouro, você só lança código que foi produzido através de uma compilação diária completa que se iniciou depois de um check out completo.
• Coloque os compiladores com o nível de avisos o mais alto possível (-W4 no mundo da Microsoft; -Wall na terra do gcc) e faça com que parem a compilação se encontrarem o mais pequeno aviso.
• Se uma compilação diária falha, você corre o risco de parar toda a equipa. Pare tudo e continue a recompilar até o erro ser corrigido. Algumas das vezes você vai compilações diárias múltiplas.
• O seu script de compilação diária deve relatar falhas, via email para toda a equipa de desenvolvimento. Não é muito difícil fazer uma procura nas logs de "error" ou "warning" e incluir isso no email. O script pode também juntar relatórios numa página HTML que é visível por todos permitindo aos programadores e testadores rapidamente verem quais as compilações diárias que foram bem sucedidas.
• Uma regra que era seguida na equipa do Excel na Microsoft, com grandes resultados, era de quem fizesse falhar a compilação diária era responsável por tratar das compilações até que alguém voltasse a fazer falhar a compilação. Adicionalmente, e a servir como incentivo inteligente para manter as compilações sem falhas, fazia com que quase todos rodassem na tarefa de mestre de compilações e todos aprendiam como as compilações eram feitas.
• Se a sua equipa trabalha num fuso horário, uma boa hora para fazer a compilação é ao almoço. Desta maneira toda a equipa faz os check in do último código desenvolvido imediatamente antes de almoço, e a compilação é feita enquanto se está a comer e quando se volta ao trabalho, se a compilação falhou, todos estão presentes para ajudar a corrigir o problema. Assim que as coisas estiverem corrigidas, toda a equipa pode voltar a fazer o check out do código mais recente sem medo de ficar encravado devido a uma compilação falhada.
• Se a sua equipa está a trabalhar em dois fusos horários, faça a compilação diária para que uma equipa a trabalhar num fuso horário não atrapalhe a equipa do outro fuso horário. Na equipa do Juno, o pessoal de Nova Iorque fazia o check in das suas coisas às 7 PM de Nova Iorque e iam para casa. Se eles fizessem a compilação falhar, e equipa em Hyderabad na Índia começava a trabalhar (por voltas das 8 PM de Nova Iorque) e poderia ficar completamente bloqueada durante um dia. Começamos então a fazer duas compilações diárias, cerca de uma hora antes de cada equipa ir para casa e assim resolvemos completamente o problema.

Para mais informações:

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