Exercícios de dicção

Exercícios de dicção	Actualizado a 2008/11/13 (2 baterias de exercícios)
1. Cada texto deve ser lido calmamente. Primeiro é preciso dizer correctamente aquilo que se lê. Num segundo momento, depois de já se ler o texto com alguma segurança, deve-se tentar dar a entoação e o ritmo que parecerem mais adequados para cada texto. B Á boca de um beco na bica do Belo Um bravo cadelo berrava: bau, bau. Um bêbado, um botas de bolsa e rabicho, embirrava com o bicho, bateu-lhe com um pau. Foi grande a balbúrdia, a turba se ria, o bruto bramia, e o broma a bater. Com o pau sobre o pobre, e bumba e mais bumba, parece um zambumba. Bendito beber. C Na toca de uma coruja numa casa escangalhada corria de canto a canto certa cobrinha cintada. Encontra um pinto calçudo que por ali andava à caça das moscas e sevandijas e que ao ver a cobra embaça. "Comadre", diz o coitado lá no seu queriquiqui, "vem caçar? Eu já cacei. Entre que eu saio daqui". Torna a cabeça escancarando a boca: "caçaste? E eu não. Mas ambos temos faxina, compadre do coração..." D Um doido destes de pedras, por nome Andrónico André, Casado com dona Aldonça, Que em vez de dois, tinha um pé. Dia de corpo de Deus, disse à esposa: "Aldonça, andai adornai com as gualdrapas, que herdei de Adão meu padrasto". "Dai-me a capa de bedel, o casaco de mandil, o meu chapéu de dedal, e a bengala d´aguazil." "Gravata dura (que é duplex), meu relógio de cadeia. O meio-dia oiço dar! Põe-me já depressa a ceia." "Venha o pudim de bedum, que a dona Dulce nos deu, e o presunto quadrilongo, do quadrúpede sandeu." E assim ceado a asseado. O tal Andrónico André, saracoteando os quadris, F Florência, Francisca, Eufrásia, todas de fraldas de folhos, foram fazer uma festa de filhós, bifes, repolhos. Três tafuis, três franchinotes, deitaram-lhes fel nos molhos, por tal feito que as três, fartas de fome e de zanga, só comeram dessa vez, fígados fritos de franga. G Eugénio Gomes da Gama e Gil Gonçalves Bugio brigaram num desafio pela grulha de uma dama. Grande desgraça e muito digna de lágrimas bem gerais! Seus golpes foram mortais, e aquela magana indigna mangou nos seus funerais. J Um janízaro em jejum viu num jardim um jarreta, que estava a jantar peru, gergelim e ginja preta. De júbilo encheu-se todo, e pregou-lhe uma peta que tirou o pé do lodo e gamou tudo ao jarreta. L Pondo loja de capela, Pantaleão do Cardeal, alardeia o que tem nela, pregando-lhe um edital: "linhas, lonas, alfinetes, lamparinas, chalés, luvas, lenços, lâmpadas, colchetes, leques, luto de viúvas. Lustres, lacre, lã, palitos, ferrolhos, lápis, lanternas, papel, galões, passarinhos, ligas de enlaçar as pernas!" Com esta longa parlanda, o feliz Pantaleão já tem pilhado um milhão e vai comprar a outra banda. M Amaro Simão de Sousa tem mendiga muito fatal: semeando qualquer coisa, jamais lhe nasce outra igual. Suponhamos que semeia mostarda ou manjericão: vem-lhe malvas, vem-lhe aveia, ou melancia ou melão. Malmequeres dão-lhe amoras, amoras dão-lhe marmelos: marmelos criam-lhe esporas, e estas moncos amarelos. Teima e afirma muita gente de moleirinha machucha que esta mendiga indecente foi manobra de uma bruxa. P Pedro Paulo Pinto Pereira, pobre pintor português, pinta portas paredes e painéis, por preços populares, para poder partir para Paris, pois pode praticar Ping-Pong, que é desporto parco, mas de prática particularmente preversa. Comprei um pinto em prata (que não há preço mais módico) uma pipa uma pata, um pote, um pente, um periódico. Depois pus tudo isto à venda, que parvo negócio fiz! um rapaz moço de tenda prometeu-me uma de xis. Qu Quem há que queira comprar em Queluz um bom quintal? No Verão é muito quente; no Inverno tal e qual. Tem quinze árvores de quina, quarenta cardos de coalho, quatro flores de quaresma que não requerem trabalho. Dá três alqueire e Quarta de quássia e doze de milho, e do líquido que esquenta: seis quartolas e um quarlilho. Qualquer pessoa querendo ver este prédio esquisito pode falar com o quinteiro Quirino Joaquim Cabrito. Que eco que há aqui! Que eco é? É o eco que há aqui. O quê, há eco aqui?! Há eco, há. R Comprei na feira do Rato, no largo das amoreiras, arroz de peru num prato arranjado pelas freiras. Sabia a chouriço moiro; era comer e gritar! Carne, rins, recheio coiro, roí sem resto deixar. Porém, fiquei muito doente, tanto que o doutor Cabral me receitou para o ventre raspas de unicórnio e tal. Um rato roendo roía o rabo do rodovalho e a Rosa Rita Ramalho de o ver roer se ria. O rato roeu a rolha da real garrafa do rei da Rússia. O Borges relojoeiro ruminara roendo raspas de raiz de romãzeira. O tambor rufará rápido: três rufos e seis batidas, para o remador desamarrar rente o remo e remar contra a corrente. O doutor receitou remédios drásticos: três colheres de óleo de rícino e raspas de rosa rara. O livro raro traz trais trechos que rapidamente se o rasga. S Nasce-se, cresce-se, desce-se... os senhores as senhoras... os senadores as senadoras... Se os seis sábios são susceptíveis, seguramente sereis satisfeito. Céus! se Cecília sabe, seus sentimentos serão sempre sinceros. Os assassinos sobre seus seios sugavam sangue sem cessar. Susana! Se saíres sai só. Sou o sempre seu Serafim Sá de Sousa. S (z) Um rapaz tendo uma Zebra metida num casarão, desancou-lhe um dia a febra que a pôs magra como um cão. A azêmola era cinzenta, e, depois daquela tosa, ficou da cor da pimenta e a atirar para fanhosa. T Triste trolha atrapalhado de taipar tanta trapeira, consertar tanto telhado, estragar tanta goteira. Na festa de Santo Entrudo entra trôpego e zoupeiro, de tamancos, tosco e rude, no interior do seu palheiro. Sentou-se num tamborete, sem dizer nem chus nem bus e pôs-se a entrudar sozinho com tripas de atum de truz. Eis trinta cães famintos (outros dizem trinta e seis) entram de tropel ladrando. Que estrago!... Agora o vereis. Trastes, trancas, tocos, troncos, estoiram...tudo é tropel. Bater, latir, tombos, roncos terminam este aranzel. V Vinde ouvir caros ouvintes. Vale a pena! Era uma vez Vitorino Vaz Ventura dos Arcos de Valdevez. Vai ele um dia e vestiu-se com a véstia verde-gris, luva nova cor de couve e verónica de Aviz. Adivinhais o motivo porque assim se ataviou? É porque ia a Vila Verde à voda do pai-avô. - Como vens viçoso e grave! Diz o pai-avô. - Trago-vos trovas em verso, lhe volve o vivo camelo. E tais trovas e tais versos dum livro lhe vomitou que virou de uma vez o bucho ao ciso do pai-avô. X Excelente chá da China em caixotes de charão trouxe a charrua xarroco, que é xaveco de feição. Além deste chá de luxo, mil coisas muito curiosas trouxe da China. Por exemplo Chambres roxos, seda fina. Chibatas e chifarotes, lenços para chischisbéus, Chorinas de franchinotes, frascos de óleo de xaréus. Xargões, enxergas, enchovas, enxofre, enxós, chocolate, enxúdias, enxertos, lixas, lagartixas e um orate. Xavier consignatário, chineiro gordo e convexo, vendo tanta esquisitice dizem que ficou perplexo.
2. Cada frase deve ser lida calmamente. Primeiro é preciso dizer correctamente aquilo que se lê. Num segundo momento, depois de já se ler o texto com alguma segurança, deve-se tentar dar a entoação e o ritmo que parecerem mais adequados para cada frase. NÍVEL FÁCIL 1. Xuxa! A Sasha fez xixi no chão da sala. 2. O rato roeu a roupa do Rei de roma a rainha com raiva resolveu remendar. 3. Três pratos de trigo para três tigres tristes. 4. O original nunca se desoriginou e nem nunca se desoriginalizará. 5. Qual é o doce que é mais doce que o doce de batata doce? Respondi que o doce que é mais doce que o doce de batata doce é o doce que é feito com o doce do doce de batata doce. NÍVEL MÉDIO 1. Sabendo o que sei e sabendo o que sabes e o que não sabes e o que não sabemos, ambos saberemos se somos sábios, sabidos ou simplesmente saberemos se somos sabedores. 2. O tempo perguntou ao tempo qual é o tempo que o tempo tem. O tempo respondeu ao tempo que não tem tempo para dizer ao tempo que o tempo do tempo é o tempo que o tempo tem. 3. Em baixo da pia tem um pinto que pia, quanto mais a pia pinga mais o pinto pia! 4. A sábia não sabia que o sábio sabia que o sabiá sabia que o sábio não sabia que o sabiá não sabia que a sábia não sabia que o sabiá sabia assobiar. NÍVEL DIFÍCIL 1. Num ninho de mafagafos, cinco mafagafinhos há! Quem os desmafagafizá-los, um bom desmafagafizador será. 2. O desinquivincavacador das caravelarias desinquivincavacaria as cavidades que deveriam ser desinquivincavacadas. 3. Perlustrando patética petição produzida pela postulante, prevemos possibilidade para pervencê-la porquanto perecem pressupostos primários permissíveis para propugnar pelo presente pleito pois prejulgamos pugna pretárita perfeitíssima. 4. Não confunda ornitorrinco com otorrinolaringologista, ornitorrinco com ornitologista, ornitologista com otorrinolaringologista, porque ornitorrinco, é ornitorrinco, ornitologista, é ornitologista, e otorrinolaringologista é otorrinolaringologista. 5. Disseram que na minha rua tem paralelepípedo feito de paralelogramos. Seis paralelogramos tem um paralelepípedo. Mil paralelepípedos tem uma paralelepipedovia. Uma paralelepipedovia tem mil paralelogramos. Então uma paralelepipedovia é uma paralelogramolândia? NÍVEL (QUASE) IMPOSSÍVEL Verbo Tagarelar no Futuro do Pretérito Eu tagarelaria Tu tagarelarias Ele tagarelaria Nós tagarelariamos Vós tagarelarieis Eles tagarelariam Retirado de : http://atelierradio.com.sapo.pt/prod/textodic.htm

Sistema de controle de versão

Exemplo da visualização do histórico de um projeto usando um sistema de controle de versões

Um sistema de controle de versão (ou versionamento), VCS (do inglês version control system) ou ainda SCM (do inglês source code management) na função prática da Ciência da Computação e da Engenharia de Software, é um software com a finalidade de gerenciar diferentes versões no desenvolvimento de um documento qualquer. Esses sistemas são comumente utilizados no desenvolvimento de software para controlar as diferentes versões — histórico e desenvolvimento — dos códigos-fontes e também da documentação.

Esse tipo de sistema é muito presente em empresas e instituições de tecnologia e desenvolvimento de software. É também muito comum no desenvolvimento de software livre. É útil, em diversos aspectos, tanto para projetos pessoais pequenos e simples como também para grandes projetos comerciais.

Entre os mais comuns encontram-se as soluções livres: CVS, Git e SVN; e as comerciais: SourceSafe e ClearCase. O desenvolvimento de software livre prefere o SVN que vem substituindo o clássico CVS. Muitas empresas também adotam o SVN, embora algumas empresas prefiram uma solução comercial, optando pelo ClearCase (da IBM) ou SourceSafe (da Microsoft). Optar por uma solução comercial geralmente está relacionada à garantia, pois as soluções livres não se responsabilizam por erros no software e perdas de informações^[1], apesar das soluções livres poderem ter melhor desempenho e segurança que as comerciais. As soluções comerciais apesar de supostas garantias adicionais não garantem o sucesso da implementação nem indenizam por qualquer tipo de erro mesmo que comprovadamente advindo do software.

A eficácia do controle de versão de software é comprovada por fazer parte das exigências para melhorias do processo de desenvolvimento de certificações tais como CMMI e SPICE.^[2]

Principais vantagens

As principais vantagens de se utilizar um sistema de controle de versão para rastrear as alterações feitas durante o desenvolvimento de software ou o desenvolvimento de um documento de texto qualquer são:

• Controle do histórico: facilidade em desfazer e possibilidade de analisar o histórico do desenvolvimento, como também facilidade no resgate de versões mais antigas e estáveis. A maioria das implementações permitem analisar as alterações com detalhes, desde a primeira versão até a última.
• Trabalho em equipe: um sistema de controle de versão permite que diversas pessoas trabalhem sobre o mesmo conjunto de documentos ao mesmo tempo e minimiza o desgaste provocado por problemas com conflitos de edições. É possível que a implementação também tenha um controle sofisticado de acesso para cada usuário ou grupo de usuários.
• Marcação e resgate de versões estáveis: a maioria dos sistemas permite marcar onde é que o documento estava com uma versão estável, podendo ser facilmente resgatado no futuro.
• Ramificação de projeto: a maioria das implementações possibilita a divisão do projeto em várias linhas de desenvolvimento, que podem ser trabalhadas paralelamente, sem que uma interfira na outra.

Funcionamento básico

Cada implementação possui sua particularidade, mas a maioria deles compartilham alguns conceitos básicos. Nota: Apesar disso, é possível que algum sistema específico funcione de maneira totalmente diferente da explicada neste capítulo.

A maior parte das informações - com todo o histórico - ficam guardadas num repositório (repository em inglês), num servidor qualquer. Geralmente o acesso é feito por um cliente pela rede (via socket) e pode ser feito localmente quando o cliente está na mesma máquina do servidor.

O repositório armazena a informação - um conjunto de documentos - de modo persistente num sistema de arquivos ou num banco de dados qualquer. É possível que o armazenamento seja feito em outros dispositivos capazes de "eternizar" e resgatar facilmente a informação.

Cada servidor pode ter vários sistemas de controle de versão e cada sistema pode ter diversos repositórios, limitando-se na capacidade de gerenciamento do software e também no limite físico do hardware. Geralmente um repositório possui um endereço lógico que permite a conexão do cliente. Esse endereço pode ser um conjunto IP/porta, uma URL, um caminho do sistema de arquivos etc.

Cada desenvolvedor possui em sua máquina uma cópia local (também chamada de working copy em inglês) somente da última versão de cada documento. Essa cópia local geralmente é feita num sistema de arquivos simples (FAT, NTFS, ext3 etc). A cada alteração relevante do desenvolvedor é necessário "atualizar" as informações do servidor submetendo (commit em inglês) as alterações. O servidor então guarda a nova alteração junto de todo o histórico mais antigo. Se o desenvolvedor quer atualizar sua cópia local é necessário atualizar as informações locais, e para isso é necessário baixar novidades do servidor (ou fazer update em inglês).

fig. a - Esquema geral físico. "Sistema" representa o sistema de controle de versão do lado Servidor (server-side). "Software Cliente" representa o sistema de controle de versão do lado Cliente (client-side).

fig. b - Esquema geral lógico.

Envio e resgate de versões

A principal função do sistema de controle de versão é armazenar todo o histórico de desenvolvimento do documento, desde o primeiro envio até sua última versão. Isso permite que seja possível resgatar uma determinada versão de qualquer data mais antiga, evitando desperdício de tempo no desenvolvimento para desfazer alterações quando se toma algum rumo equivocado.

O envio das alterações é feito a gosto do desenvolvedor (do lado do cliente), quando ele desejar; mas, para minimizar conflitos de versões, facilitar no desfazer de alterações e também no controle do histórico, recomenda-se que uma alteração seja enviada cada vez que o software estiver minimamente estável, i. e., a cada nova parte (uma função, e. g.) ou a cada alteração relevante que esteja funcionando corretamente. Não é recomendável o envio quando o documento como um todo possa causar alguma dificuldade no desenvolvimento de outro colaborador, como por exemplo um código não compilando ou com algum defeito que comprometa a execução geral.

Cada "envio" é na maioria dos sistemas chamado de "commit" (as vezes "submit"), ou seja, efetivar as alterações no (ou "submeter" ao) repositório. Cada envio produz uma nova versão no repositório e é armazenado como "uma fotografia" do momento.

fig. c - Em sistemas no estilo do CVS, cada documento tem sua versão controlada individualmente. Assim, é necessário adicionar marcas ('tags' - em inglês) para que se tenha uma "fotografia" de determinado momento. Ou seja, o versionamento do conjunto fica a cargo do usuário pois a numeração gerada pelo sistema de controle de versão não fornece "alinhamento" aos documentos.

fig. d - Já em sistemas no estilo do SVN, o controle de versão é feito por cada envio ao servidor. Ou seja, há uma versão global para todos os documentos. Se você enviar 4 versões do arquivo B enquanto você enviou apenas 2 versões do A, ambos estão na versão final que é a 4. Perceba que toda "fotografia" de qualquer momento será sempre uma coluna alinhada como mostra a figura.

Se o arquivo fosse armazenado diretamente num sistema de arquivos simples, não haveria histórico, a menos que isso fosse feito manualmente através de cópias completas dos documentos numa organização (que pode ou não envolver pastas) que dependerá do desenvolvedor.

fig e - Num sistema de arquivos simples, sem controle de versões, seria necessário fazer cópias manualmente para manter as versões anteriores, o que poderia se tornar muito confuso com o tempo conforme o número de versões aumentam.

Histórico de envio

Muitas vezes, é possível acrescentar comentários no envio das alterações, o que facilita também uma possível análise do histórico. Geralmente o relatório com as versões e os comentários de cada envio são chamados de "histórico" ou "log", e uma análise deste relatório pode facilitar em muitos aspectos no desenvolvimento do produto.

A documentação do CVS, SVN e outros, recomendam que o comentário do histórico seja amplo, geral e abstrato, ou seja, que não se limite à explicação da mudança do código em si, mas sim sobre o que foi mudado ou acrescentado no conceito ou no funcionamento como um todo. A mudança do código pode ser analisada através de uma diferença (ou diff) entre duas versões, portanto o comentário seria útil apenas para explicar a mudança de forma lógica.

Exemplo prático dessa recomendação: utilize "acréscimo de uma condição que verifica se existe saldo na conta para não permitir que seja sacado sem saldo" ao invés de um comentário contendo o próprio código modificado como:

"+ if (!this.haSaldoNaConta()) { this.proibeSaque() }"

Trabalho em equipe

Sistemas de controle de versão também são convenientes quando diversos desenvolvedores trabalham sobre o mesmo projeto simultaneamente, resolvendo eventuais conflitos entre as alterações. A maioria dos sistemas possui diversos recursos como ramificação e mesclagem de histórico para auxiliar nessas tarefas.

Para que seja possível o trabalho em equipe, o sistema de controle de versão pode possuir um mini sistema de controle de usuários embutido ou pode utilizar algum outro sistema de autenticação separado. Assim, é possível identificar cada usuário, que geralmente fica protegido por uma senha pessoal, ou alguma senha criada pelo administrador de sistemas.

No CVS, por exemplo, é possível escolher o método de autenticação a ser usado, dentre várias opções. No caso do SVN, por exemplo, se ele estiver rodando via Apache, o controle de usuários poderá ser feito pela autenticação padrão do Apache. Embora menos comum, é possível também configurar o SVN para utilizar o usuário do sistema, como os usuários do Linux ou do Windows.

Mesclagens Otimistas vs Edições Exclusivas

Com relação ao trabalho em equipe num sistema de controle de versão, há basicamente dois métodos (ou filosofias) relevantes de edição:

• "Optimistic Merges" ("Mesclagens Otimistas") ou "Branch and Merge" ("Ramificando e Mesclando") ou ainda "Copia-modifica-resolve"^[2]
• "Exclusive Lock" ("Tranca exclusiva", "Edições exclusivas") ou ainda "Trava-modifica-destrava"^[2])

Nota: a ausência de um sistema de controle de versão, ou seja, o trabalho direto num sistema de arquivos comum é equivalente ao "Exclusive Lock" nesse aspecto. Há também alguns sistemas, como o MediaWiki (pelo menos até a versão 1.8) e. g., que permitem a edição simultânea (sem trancar ou bloquear o outro) mas que não gerenciam automaticamente os conflitos, tendo que ser feitos manualmente sempre.

A filosofia "Optimistic Merges" ("Mesclagens Otimistas"), é um método de conflitos otimista que é geralmente padrão na maioria dos sistemas abertos, como o SVN e CVS. Essa filosofia presume que os conflitos de edições são tão pequenos e pontuais — se houver relativa atualização frequente do repositório por ambos — que a grande maioria das fusões podem ser feitas de forma automática, restando para fusões manuais somente casos em que a alteração for feita num mesmo ponto de um mesmo arquivo. A prática demonstra que essa visão é, na verdade, também a mais realista. O capítulo #"Demonstração de Mesclagens Otimistas" demonstra como esse método funciona na prática.

Em contrapartida, numa visão mais pessimista (ou "conservadora"), pode-se afirmar que, se houver muitas modificações simultâneas sem intervalos pequenos de atualização mútua num mesmo arquivo, é possível que a fusão manual se torne tão complicada a ponto de desperdiçar parcialmente ou totalmente o trabalho de um ou de outro editor usuário do sistema. É por esse principal motivo que alguns sistemas, geralmente as soluções comerciais como o ClearCase e o SourceSafe, adotam outro método de trabalho como padrão: o "Exclusive Lock" ("Tranca exclusiva" ou "Edições exclusivas"). Esse método consiste basicamente em deixar apenas um usuário editar um arquivo de cada vez, sendo que este fica bloqueado enquanto não houver um reenvio (atualização) do editor ao servidor. É possível mesclagem neste método, mas apenas após a liberação (ou desbloqueio) do editor. O capítulo #"Edições Exclusivas" ou ausência de um sistema de controle de versão demonstra como esse método funciona na prática.

Demonstração de "Mesclagens Otimistas" passo-a-passo

A seguir, é demonstrado em alguns passos, numa edição fictícia, como funciona o método de "Mesclagens Otimistas". Cada animal personificado a seguir nas figuras - Pig, Dog e Panda - representam um programador independente (com ou sem comunicação entre si), que podem estar em locais físicos separados.

1° passo: atualizando

fig f - todos atualizam sua versão local. (geralmente comando update)

2° passo: desenvolvendo

fig g - todos trabalham simultaneamente, perceba que o Dog e o Panda estão modificando o mesmo documento porém em locais diferentes (linhas distintas).

3° passo: submetendo

fig h - Pig e Dog terminaram o trabalho e submetem (commit) as alterações ao Servidor através do software Cliente. Perceba que o Panda ainda não terminou o trabalho.

4° passo: necessita atualização

fig i - Panda tenta enviar o arquivo ao Servidor, mas não consegue porque o Cliente alerta que há uma versão mais atualizada. No caso, é a versão do documento C que Dog submetera anteriormente.

5° passo: baixando atualização e mesclando

fig j - Nesse caso Panda precisa atualizar (update) sua versão local antes de submeter as alterações. Geralmente o software Cliente faz uma cópia de segurança do arquivo local antes de tentar mesclar (merge) as diferenças. Nesse caso, como na maioria dos casos reais, Panda e Dog modificaram locais diferentes no arquivo e o Cliente conseguiu mesclar as diferenças com sucesso. Nesse caso, ele inclui na versão local tanto a alteração de Dog quanto a de Panda. A maioria dos sistemas analisa as diferenças por linha alterada, mas é possível que esse bloco seja por parágrafo ou até por letras. Quando a mesma região do documento é modificada acontece o conflito e ele precisa ser resolvido manualmente; esse caso será melhor explicado depois.

6° e último passo: submetendo a versão final

fig k - Depois de mesclado com sucesso, Panda testa para ver se realmente está tudo OK e simplesmente reenvia (commit) ao Servidor através do Cliente.

"Edições Exclusivas" ou ausência de um sistema de controle de versão

No método mais conservador, ou quando se compartilha o mesmo projeto numa rede diretamente num sistema de arquivos simples, sem um sistema de controle de versão, alguns arquivos ficam bloqueados para escrita enquanto estão sendo utilizados. Ainda, um agravante na ausência do sistema de controle de versão, é que o fluxo de informações pela rede é alto porque a cada modificação substancial é necessário reenviar o documento todo e a chance de corromper arquivos também aumenta; o que não acontece com um sistema de controle de versão, pois cada desenvolvedor possui uma cópia local do projeto, trabalhando localmente, baixando as atualizações e enviando as alterações.

fig l - (compare com a fig. f) Perceba a dificuldade em trabalhar em equipe utilizando um compartilhamento simples de arquivos pela rede. No exemplo da figura, o desenvolvedor Panda está ocioso enquanto Dog não terminar de trabalhar com o documento C. Diferentemente, quando se utiliza um sistema de controle de versões cada desenvolvedor pode trabalhar tranquilamente em sua cópia local e o sistema fica encarregado de mesclar o que for necessário de acordo com as mudanças simultâneas.

Mesclagem no método "Edições Exclusivas"

A mesclagem no método "Edições Exclusivas" é ainda possível desta forma:

1. usuário A dá checkout (ou update).
2. B tenta dar checkout e não consegue porque A está bloqueado.
3. B dá checkout não reservado (sem bloquear).
4. B tenta dar commit (ou checkin), mas não consegue, B fica aguardando A liberar o lock (bloqueio).
5. A dá commit ou release, liberando a trava.
6. B dá um update & merge (que já cria um lock para ele).
7. B dá commit com a versão mesclada.

Bloqueio de arquivo

Alguns sistemas permitem o bloqueio voluntário de qualquer arquivo. Alguns sistemas que suportam são o CVS e SVN (a partir da versão 1.2.0), por exemplo.

A opção de bloquear um arquivo é muito útil nos seguintes casos:

• Quando há trabalho simultâneo num mesmo arquivo de difícil ou impossível mesclagem.
• Ao editar um arquivo binário (que não permite a mesclagem), como arquivos compactados, bibliotecas, imagens etc. Não é muito recomendável trabalhar com arquivos binários num sistema de arquivos, porém muitas vezes é útil deixar arquivos binários junto do código-fonte ou da documentação, principalmente em casos em que é difícil gerar esses arquivos, como imagens, algumas bibliotecas etc.
• Quando há muita dificuldade na comunicação entre os desenvolvedores e conflitos freqüentes que desperdiçam muito tempo manual de mesclagem.

Comparação de versões

É possível, na grande maioria dos sistemas de controle de versão (e quando o tipo de arquivo permite isso), comparar (também chamado de diff ou diferença) quaisquer versões entre si, enviadas a qualquer tempo. Saber exatamente o que foi acrescentado, modificado ou excluído em qualquer ponto dos documentos. Isso permite que seja feito uma análise minuciosa das alterações desde a criação do projeto até seu estado atual.

Analise esta figura e veja um exemplo prático real de uma diferença entre duas versões: (também neste link: [1]). Essa diferença é feita pelo software MediaWiki que exibe a diferença com cores diferentes e símbolos para facilitar o entendimento. A cor amarela indica que a linha foi retirada, a cor verde que a linha foi colocada e a cor vermelha indica qual palavra ou trecho foi modificado dentro da linha. O símbolo (+) indica que foi acrescentado e o (-) que foi retirado.

Conflitos

É chamado de conflito de edição a situação em que dois ou mais usuários modificam o mesmo documento no mesmo intervalo de tempo entre o envio de uma nova versão ao sistema. A chance de conflitos aumentam quando aumentam o número de usuários utilizando o mesmo conjunto de documentos. O envio de alterações muito grandes podem também aumentar a chance de conflito.

Mesclagem

A mesclagem (ou merge em inglês) consiste na aglutinação (ou fusão) automática de versões através da comparação entre elas, quando há um conflito de edições simples.

Quando um conflito é direto, ou seja, no mesmo ponto do mesmo documento e o sistema não conseguiu resolver o conflito automaticamente, a mesclagem pode ser feita manualmente. Algumas implementações como o MediaWiki (até a versão 1.8 pelo menos) não possuem o sistema de "mesclagem", portanto quando há qualquer conflito, mesmo os mais simples, é necessário resolvê-lo manualmente como descreve a seção #Resolução manual de conflitos.

Resolução manual de conflitos

Quando dois ou mais desenvolvedores modificam uma mesma região num documento é necessário resolver o conflito "manualmente". O software de Cliente fará uma cópia de segurança da sua alteração para que não haja chance de você perdê-la e depois mostrará o local de conflito. O software geralmente mostra os conflitos na tela e o desenvolvedor escolhe qual versão manter. Geralmente quando acontece esse tipo de coisa é porque houve falha na organização de divisão do trabalho e provavelmente uma alteração semelhante foi produzida na mesma região.

Ramificações e marcações

Num sistema moderno de controle de versões é possível quebrar a linha do desenvolvimento em mais de um caminho. Isso pode ser chamado de ramificação (ramo), braços ou em inglês branches. Isso é muito útil quando se conquista uma versão estável dos documentos (ou software) ou quando se quer fazer uma tentativa "não convencional" fora do ramo principal.

Otimização de espaço e velocidade

Geralmente um sistema assim mantém armazenado apenas a primeira versão e as diferenças entre elas, até formar a última, com o principal objetivo de economizar espaço. É claro que também existem outras otimizações que guardam a versão final ou versões recentes para que algumas operações possam ser feitas de modo mais rápido (utilizando uma espécie de cache). É possível também, dependendo do sistema e da configuração, que seja compactado algumas partes do repositório muito antigas que não estão sendo utilizadas de modo a salvar espaço.

Os sistemas são otimizados para trabalhar com arquivos texto e muitas vezes não se dão muito bem com arquivos binários. Sistemas mais modernos trabalham melhor com esse segundo tipo de arquivo, mas ainda assim de forma pouco satisfatória: tanto pelo alto consumo de espaço quanto pela dificuldade de se fazer comparação entre uma versão e outra.

Sistemas como o CVS e o SVN recomendam que documentos textos que necessitam de estilos, formatações especiais, tabelas e figuras, tais como o arquivo DOC do Microsoft Word que são em binário, sejam gravados em algum formato texto como o Rich Text Format (RTF), HTML ou XML (com quebras de linha entre uma tag e outra^[3]) porque internamente ele guarda a informação em texto. Um texto desse tipo não fica tão otimizado quanto um texto simples, mas ainda assim fica melhor que um arquivo binário.

Integração com outros softwares

Os sistemas de controle de versões mais flexíveis permitem que seja possível integrá-los a outros softwares. A integração mais comum é em IDE (ambientes de desenvolvimento) através de plugins. Alguns ambientes que suportam a integração de alguns sistemas são: IntelliJ IDEA, Eclipse, NetBeans e Visual Studio. O TortoiseSVN, o TortoiseCVS e o TortoiseHg, clientes do SVN, do CVS e do Mercurial, respectivamente, funcionam sobre o Windows Explorer.

Vocabulário comum

• Atualização / Update - Atualiza na cópia local as novidades do Servidor, provavelmente as mudanças enviadas por outro desenvolvedor.
• Baixar / Check-out ou checkout - Quando não existe cópia local e é necessário baixar todo o projeto do servidor. Nesse processo é guardado algum tipo de meta-dados (geralmente em pasta oculta) junto dos arquivos baixados.
• Conflito / Conflict - É a alteração simultânea (entre um update e um commit) de um mesmo documento por usuários diferentes.
• Cópia local / Working copy ou working area - É geralmente uma pasta no sistema operacional do desenvolvedor (do lado Cliente) que mantém a cópia da última versão do projeto. É através da cópia local que o Cliente compara com a última versão do Servidor e sabe exatamente o que foi modificado.
• Efetivar ou submeter / Commit, submit ou check-in - Enviar as alterações da cópia local ao Servidor através do Cliente.
• Exportar / Export - Semelhante ao checkout, mas não cria meta-dados junto da informação baixada. Esse processo é utilizado para gerar uma versão "distribuível" e impede (por não conter os meta-dados) que o desenvolvimento seja feito sobre ele.
• Importar / Import - É o processo que envia uma árvore de diretórios ainda não controlada (sem meta-dados) para o repositório pela primeira vez.
• Marcação / Tag ou release - É dar um nome a um determinado "momento" do repositório, ou seja, é como uma "fotografia" de determinada data. Alguns sistemas, como o SVN, não diferenciam entre "marcação" e "ramificação", pois é possível tratar uma ramificação com o conceito ou finalidade de marcação.
• Mesclagem / Merge ou integration - Permite que mais de um utilizador modifique um mesmo documento ao mesmo tempo, comparando as diferenças e mesclando mantendo as duas alterações (se possível). A mesclagem geralmente é feita localmente (lado Cliente) na atualização de um documento quando há uma versão no Servidor mais recente que a sua.
• Mesclagem inversa / Reverse integration - É quando um braço é mesclado à linha principal.
• Modificação, diferença ou mudança (Change ou diff.) - Representa a diferença entre uma versão e outra de um mesmo documento.
• Raiz, linha principal ou braço principal / Head, trunk, mainline - é o caminho de revisões que não se quebrou em um braço.
• Ramificação ou braço / Branch - Quando a linha de desenvolvimento precisa ser dividida em duas ou mais.
• Repositório / Repository - local no Sistema onde fica armazenado todas as versões, desde a primeira até a última. Cada sistema geralmente pode ter mais de um repositório.
• Resolução de conflito / Conflict resolve ou Solve - Quando os desenvolvedores precisam analisar o que entrou em conflito e escolher qual alteração fará parte da versão final.
• Revisão ou versão / Revision ou version - Representa um determinado "momento" (uma "fotografia") de um repositório ou documento.
• Travar / Lock - Em alguns sistemas é possível bloquear um arquivo e ninguém pode alterá-lo nesse momento. Isso é pouco usado e pouco recomendado pois impede o uso simultâneo do mesmo arquivo por mais de um desenvolvedor, mas pode ser bastante útil com arquivos binários e/ou difíceis ou impossíveis de serem mesclados.
• Última versão / last revision - é a última versão enviada ao sistema no braço principal.
• Versão atualizada / Up-to-date - É quando a versão local é idêntica à que está no servidor. Quando alguém submete um documento (que você também está trabalhando) antes de você, o sistema não permite que você envie a sua versão enquanto você não deixar sua versão local atualizada (up-to-date).
• Versão estável / Stable version - Chama-se de "versão estável" uma determinada versão do sistema que está compilando normalmente e não possui nenhuma anomalia grave.
• Versão instável / Unstable version - Chama-se de "versão instável" uma versão do sistema que não está compilando ou que possui alguma anomalia bastante visível e geralmente grave.

Lista de sistemas de controle de versão

Segue uma lista dos mais conhecidos:

Soluções comerciais

• Microsoft Visual SourceSafe (VSS) - produto da Microsoft para controle de versão, integrado a muitas IDEs da Microsoft.
• Rational ClearCase - produto da IBM para controle de versão.
• Borland StarTeam - produto da Borland para controle de versão e de equipe.

Soluções livres

• Concurrent Version System (CVS) - software livre clássico e bem testado.
• Subversion (SVN) - alternativa também livre e mais eficiente que o CVS. Muitas fundações não-governamentais sem fins lucrativos ligadas ao desenvolvimento de software internacionalmente reconhecidas como a Apache Foundation já adotaram o Subversion como padrão.
• Git - Software para controle de versão distribuído com foco na velocidade.^[4].
• MediaWiki - software livre que possui um sistema integrado de controle de versões. Sites com os projetos da Wikimedia, tal como a Wikipédia mantém o sistema MediaWiki para o controle das versões dos documentos. Esse sistema permite o trabalho simultâneo de milhares de voluntários.
• GNU CSSC
• Revision Control System (RCS)
• Bazaar^[5]
• Darcs
• Mercurial - SCM usado para gerenciar o código fonte do Python
• Monotone
• SVK

Para uma lista completa com comparações visite Lista de sistemas de controle de versão.

Notas e referências

1. ↑ Geralmente as licenças consideradas "livres" explicitam que o autor não se responsabiliza e não há nenhum tipo de garantia por qualquer prejuízo que se tenha no uso. A licença GNU General Public License, por exemplo, é bem clara: "Este programa é distribuído na expectativa de ser útil, mas SEM QUALQUER GARANTIA; sem mesmo a garantia implícita de COMERCIALIZAÇÃO ou de ADEQUAÇÃO A QUALQUER PROPÓSITO EM PARTICULAR. (...)"
2. ↑ ^{a b c} Conceitos Básicos de Controle de Versão de Software, por André Felipe Dias publicado por Pronus Engenharia de Software (04/08/2006)
3. ↑ A quebra de linha num HTML ou XML é altamente recomendada porque geralmente um sistema de controle de versão faz a análise das diferenças linha-por-linha e não caractere-por-caractere. Assim sendo, se o XML possuir uma única linha com todas as tags, por exemplo, uma diferença entre uma versão e outra seria a da linha toda sempre, mesmo que a alteração tenha sido num ponto específico.
4. ↑ Inicialmente desenvolvido por Linus Torvalds, criador do Linux, mantém o controle de versões do núcleo Linux. O grande diferencial é a alta velocidade. Ver http://git.or.cz/
5. ↑ Ver http://bazaar-vcs.org

Bibliogafia

• MOLINARI, Leonardo. Gerência de Configuração - Técnicas e Práticas no Desenvolvimento do Software. Florianópolis: Visual Books, 2007. 85-7502-210-5
• MIKKELSEN, Tim, PHERIGO, Suzanne. Parctical Software Configuration Management: The Latenight Developer's Handbook. Upper Saddle River, NJ, EUA: Prentice Hall PTR, 1997. 0-13-240854-6
• Cristiano Caetano. CVS: Controle de Versões e Desenvolvimento Colaborativo de Software. [S.l.]: ed. Novatec, 2004.

Ver também

• Gerência de Configuração de Software

Ligações externas

• Manual Completo do Subversion (SVN)
• Site oficial do Subversion (SVN)
• WinCVS (CVS para Windows)
• Referência Debian Capítulo 12 - Sistemas de Controle de Versão (Resumo de alguns comandos do CVS)

retirado de: http://pt.wikipedia.org/wiki/Sistema_de_controle_de_vers%C3%A3o

Boas Práticas na Utilização de Controle de Versão

Controle de versões representa a possibilidade de compartilhar arquivos, armazenar todas alterações e resolver os conflitos de edição. A sua utilização é fundamental durante todo o ciclo de desenvolvimento, armazenando artefatos de especificações até o código fonte.

Com o controle de versão é possível que diversos desenvolvedores editem o mesmo documento e todas alterações sejam armazenadas para que o histórico seja mantido e conflitos nas edições solucionados. Outra função muito importante do controle de versões é armazenar todas alterações que um documento sofreu e permitir a recuperação de qualquer uma das versões anteriores.

Embora a utilização de controle de versões possa facilitar a vida dos desenvolvedoes, a falta de organização e padronização pode levar a mais problemas do que soluções.

A seguir serão apresentadas algumas boas práticas referentes a utilização de ferramentas de controle de versão, mais especificamente o Subversion, retiradas de algumas das referências citadas ao final do documento.

Usar um layout de repositório adequado

Há alguns pontos a considerar quando se está configurando um repositório do Subversion. O primeiro deles é se será criado um único repositório para vários projetos, ou um repositório para cada projeto, ou então alguma forma de combinação das duas opções. Há prós e contras em cada uma das opções.

Há benefícios ao se utilizar um único repositório para vários projetos, e o mais óbvio deles é evitar a duplicidade de manutenção:

• Um único backup a ser feito periodicamente;
• Um único ponto a exportar e carregar quando há uma nova versão do Subversion que é imcompatível com as anteriores;
• Facilidade para mover dados entre projetos, e sem perder o histórico destes dados (mover dados entre repositórios diferentes causa a perda do histórico dos dados).

A contrapartida de se utilizar um único repositório para vários projetos é que:

Diferentes projetos podem ter diferentes requisitos de autorização e autenticação;
O Subversion utiliza números de revisão que são globais no repositório; isso faz com que mudanças em projetos distintos aumentem o número de revisão de projetos não relacionados.

O meio termo seria ter alguns repositórios criados, e cada um deles conter projetos relacionados. Desta forma, os projetos relacionados podem compartilhar dados facilmente, e caso novas revisões sejam criadas no repositório, elas estarão relacionadas a projetos que estão, de alguma forma, também relacionados.

Além da organização dos repositórios em si, há ainda a questão da organização dentro dos repositórios. Há várias maneiras de organizar o repositório de um projeto, pois cada divisão existente não é nada mais do que um diretório, e o Subversion não impede a criação de diretórios. Embora exista esta flexibilidade, o projeto Subversion recomenda, oficialmente, a idéia de um “projeto raiz“ que representa o ponto principal de um projeto. Um repositório pode conter um ou mais “projetos raiz“, e o “projeto raiz“ possui exatamente três subdiretórios:

/trunk - o diretório onde o desenvolvimento principal do projeto ocorre, ou seja, onde sempre está a versão mais recente dos artefatos oficiais;
/branches – o diretório onde pode-se criar ramificações da linha principal de desenvolvimento (trunk);
/tags – o diretório onde se pode armazenar ramificações da linha principal que são criadas, e talvez destruídas, mas nunca modificadas.

Um repositório poderia se parecer com o seguinte:

view sourceprint?

01

calc/

02	----trunk/

03

----tags/

04	----branches/

05

calendar/

06	----trunk/

07

----tags/

08	----branches/

09	spreadsheet/

10	----trunk/

11

----tags/

12	----branches/

Se há múltiplos projetos em um mesmo repositório, é possível organizá-los em grupos dentro do repositório, colocando projetos com objetivos similares em subdiretórios, como a seguir:

view sourceprint?

01

02

utils/

03

----calc/

04	--------trunk/

05	--------tags/

06	--------branches/

07	----calendar/

08	--------trunk/

09	--------tags/

10	--------branches/

11

…

12

office/

13	----spreadsheet/

14	--------trunk/

15	--------tags/

16	--------branches/

Faça o commit de conjuntos lógicos de mudanças

É importante ficar bem claro que o objetivo principal de um sistema de controle de versão não é o de realizar backup dos dados versionados, mas manter o controle de versões lógicas de modificações feitas nos artefatos.

Sendo assim, realizar um commit apenas ao final do dia, com a idéia de que se está salvando o trabalho feito não é nada bom se este trabalho não estiver logicamente completo. Agindo assim só se está realizando um backup diário do trabalho.

Uma operação de commit deve ter um significado maior: ela deve refletir um trabalho completo para corrigir um erro, a incorporação completa de uma nova funcionalidade ao sistema, ou alguma tarefa particular, mas sempre por completo. Uma operação de commit irá gerar um identificador globalmente reconhecido dentro do repositório, que identifica este trabalho por completo, como se fosse um nome. Este identificador poderá ser utilizado, posteriormente, para identificar uma correção em uma ferramenta de acompanhamento de solicitações, ou então ser passado como parâmetros a comandos do Subversion quando se deseja desfazer uma mudança, ou então copiá-la de um branch a outro.

Utilizar ferramentas de acompanhamento de solicitações de maneira adequada

Ao utilizar ferramentas de acompanhamento de solicitações (correção de bugs, novas funcionalidades, etc…) faça links cruzados entre o número da solicitação aberta e do commit, ou commits que a atendem.

Uma maneira de fazer isso é incluir o número da solicitação que se está atendendo no comentário do commit, e adicionando o número da revisão, resultante do commit, nos comentários que se faz em uma solicitação, para explicar seu andamento ou seu encerramento.

Acompanhar operações de merge manualmente

Ao realizar um commit depois de uma operação de merge, escreva uma mensagem descritiva explicando o que foi integrado, como por exemplo:

Realização da integração das versões 3490:4120 do /branches/algumbranch para /trunk.

Saber quando criar branches

O debate sobre quando criar branches, ou não, é um detabe antigo, e realmente não há uma palavra final sobre isso, pois cada equipe ou projeto pode assumir uma política diferente. A seguir são descritas as três políticas mais comuns de criação de branches:

Nunca criar branches

Eesta é a política utilizada por projetos que acabaram de nascer, e que ainda não têm código executável.
Os usuários realizam o commit das mudanças diárias diretamente no /trunk.

Eventualmente o /trunk pode parar de funcionar (não compila, não passa em testes unitários), quando alguém realiza o commit de mudanças complexas.

Prós:
* É uma política fácil de seguir.
* Novos desenvolvedores têm uma barreira menor para iniciar.
* Ninguém precisa saber como criar branches e realizar integrações (merge).
Contras:
* Desenvolvimento caótico.
* O código pode se tornar instável a qualquer momento.

Sempre utilizar branches

Esta é a política utilizada por projetos que favorecem um forte gerenciamento e supervisão.
Cada usuário cria e trabalha em um branch privado para cada tarefa de codificação.

Quando a codificação está completa, alguém (o autor original do código, um colega ou o gerente) revisa todas as modificações no branch as integra ao /trunk.

Prós:
* Há a garantia de que o /trunk sempre estará consistente e estável.
* Nenhum desenvolvedor precisa manter em sua máquina, por muito tempo, modificações incompatíveis com o /trunk.
Contras:
* Os desenvolvedores ficam artificialmente isolados uns dos outros, possivelmente criando mais conflitos de integração que o necessário. Requer que os desenvolvedores façam integrações com maior frequência, para diminuir os conflitos.

Criar branches quando necessário

Esta é a prática utilizada pelo projeto Subversion.

Os usuários realizam o commit das mudanças diárias diretamente no /trunk.

Regra #1: o /trunk tem que compilar e passar nos testes de regressão sempre!
Regra #2: uma operação de commit de um conjunto de modificações não pode ser tão grande a ponto de desencorajar a revisão por parte de um colega.
Regra #3: se as regras #1 e #2 entrarem em conflito (exemplo: é impossível realizar uma série de commits sem corromper o /trunk) então o desenvolvedor deve criar um /branch e realizar uma série de commits de pequenos conjuntos de modificações lá. Isso permite que seja feita a revisão por parte de um colega, sem desestabilizar o /trunk.

Pros:
* Tem-se a garantia de que o /trunk está estável todo o tempo.
Contras:
* Adiciona algumas obrigações ao trabalho diário dos usuários: eles devem compilar e testar o código antes de cada commit realizado.

Tenha cuidado ao realizar a atualização de sua área de trabalho

Alguns cuidados, apesar de muito básicos, são ignorados por quem está começando a utilizar um sistema de controle de versão. Vejo constantemente amigos reclamando de estagiários que fazem uma verdadeira bagunça no código versionado, sobrescrevendo atualizações de colegas, criando com isso muitos problemas.

Ao invés de realizar um commit direto em algum artefato, é adequado verificar se há atualizações pendentes para o mesmo. Plugins dificilmente permitem que se realize um commit em um código que possui uma versão mais nova no servidor, mas ainda assim é uma boa prática.

Quando não há conflitos nos arquivos é difícil fazer alguma besteira. Os problemas surgem com eles.

Os plugins das IDEs permitem que se faça a verificação dos conflitos, e a solução deles, passo-a-passo. Ainda assim muitas pessoas (acreditem) ignoram os conflitos e simplesmente forçam um commit de suas atualizações, “matando” as modificações de seus colegas. Acredite, se você não quer ter sua mãe escumungada pelos seus colegas, seja cauteloso. Ao solucionar conflitos, tenha paciência e copie para sua versão as atualizações pertinentes feitas pelos seus colegas. Quando o trecho em conflito refletir uma mesma mudança feita por você e outra pessoa, verifique com a pessoa o que ela acha melhor manter na versão, principalmente se você não conseguir entender a codificação dela.

Só faça o commit quando você tiver certeza de que as mudanças feitas pelos outros colegas de trabalho foram contempladas em sua versão. Se você não conseguir resolver os conflitos, chame uma pessoa mais experiente.

Quando você não tiver uma pessoa disponível para lhe ajudar a resolver os conflitos, é preferível copiar seu código para um arquivo de backup, aceitar todas as atualizações do servidor (sobrescrevendo as suas) e depois realizar novamente as suas alterações sobre a nova versão. Isso porque você certamente entenderá melhor as suas modificações do que a de seus colegas. Esta é uma prática que eu uso às vezes (quando há conflitos demais), e vários colegas me dizem também usar a mesma prática. Pelo menos se garante que nenhum trabalho alheio será estragado.

Quando tiver novas dicas para este post eu o atualizarei.

Está dada a dica!

Referências

http://svn.apache.org/repos/asf/subversion/trunk/doc/user/svn-best-practices.html

http://svnbook.red-bean.com/

http://www.iovene.com/21

Retirado de :

Como Relatar Bugs De Maneira Eficaz

Como Relatar Bugs De Maneira Eficaz

por Simon Tatham, programador professional e de softwares de código-livre. Tradução para o português por CJr.

[ English | Português | 简体中文 | Česky | Dansk | Deutsch | Español | Français | Magyar | Italiano | Nederlands | Polski | Русский | 繁體中文 ]

Introdução

Qualquer um que tenha escrito software para uso público provavelmente recebeu ao menos um relatório de bugs ruim. Relatórios que não dizem nada ("Isso não funciona!"); relatórios que não fazem sentido; relatórios que trazem informações erradas. Relatórios contendo problemas que acabam por ser identificados como erros de usuário; relatórios de problemas que acabam sendo identificados como falhas de um programa externo; relatórios de problemas que acabam sendo identificados como falhas de rede.

Existe uma razão pela qual o suporte técnico é visto como um trabalho horrível para se fazer, e esta razão são os relatórios de bugs ruins. Entretanto, nem todos os relatórios de bug são desagradáveis: eu mantenho software livre quando não estou ganhando a vida, e algumas vezes recebo relatórios de bug maravilhosamente claros, úteis, informativos.

Neste ensaio vou tentar identificar claramente o que faz um relatório de bugs ser bom. Idealmente, eu gostaria que todo o mundo lesse esse ensaio antes de fazer qualquer relatório de bug para qualquer um. Certamente eu gostaria que todos os que fizessem relatórios de bug para mim o lessem.

Sinteticamente, o objetivo de um relatorio de bug é tornar os programadores capazes de ver a falha do programa acontecer em frente aos seus olhos. Você pode mostrar a eles pessoalmente, ou fornecer-lhes instruções detalhadas e cuidadosas sobre como fazer o programa falhar. Se eles puderem fazê-lo falhar, tentarão obter informações extras até descobrirem a causa da falha. Se eles não podem fazê-lo falhar, vão ter que pedir a você para conseguir essas informações para eles.

Quando fizer relatórios de bug, tente fazer uma distinção muito clara entre os fatos reais ("Eu estava no computador e isso aconteceu") e especulações ("Eu acho que o problema pode ser esse"). Se quiser, deixe de fora as especulações, mas não os fatos.

Quando você relata um bug, é porque deseja que ele seja consertado. Não faz sentido massacrar os programadores ou ser deliberadamente obscuro: o erro pode ser deles e o problema seu, e você pode estar certo em estar com raiva deles, mas o bug vai ser consertado mais rapidamente se você ajudá-los fornecendo todas as informações de que eles precisam. Lembre-se também de que se o programa é gratuito, então os autores estão fornecendo-o por bondade. Se muitas pessoas forem rudes com eles, eles podem deixar de ser bons.

"Isso não funciona."

Dê aos programadores o crédito de possuírem uma inteligência de nível básico: se o programa realmente não tem nada que funcione, eles provavelmente teriam notado. Como não notaram, ele tem que estar funcionando com eles. Portanto, ou você está fazendo alguma coisa diferente do que eles fazem ou seu ambiente é diferente do deles. Eles precisam de informação; fornecer essa informação é o propósito de um relatório de bug. Mais informação é quase sempre melhor que menos informação.

Muitos programadores, particularmente os que trabalham em softwares livres ou gratuitos, publicam suas listas de bugs conhecidos. Se você encontrar uma lista de bugs conhecidos, vale a pena lê-la para verificar se o bug que você encontrou já é conhecido. Se já é, provavelmente não vale a pena relatá-lo novamente, mas se você acha que tem mais informações para fornecer do que as que constam na lista, deve entrar em contato os programadores. Eles podem consertar o bug mais facilmente se você puder fornecer a eles informações que eles ainda não têm.

Este ensaio está cheio de diretrizes. Nenhuma delas é uma regra absoluta. Programadores específicos gostam de maneiras específicas de relatar bugs. Se o programa vem com diretrizes próprias sobre como relatar bugs, leia-as. Se as dicas que vem com o programa contradizem as descritas neste ensaio, siga-as!

Se você não está relatando um bug, mas apenas pedindo ajuda para utilizar o programa, deveria deixar claro que já procurou pela resposta para a sua pergunta ("Li a seção 5.2 e o capítulo 4, mas não encontrei nada que me dissesse se o que quero fazer é possível.") Isto vai permitir aos programadores saber como as pessoas esperam encontrar as respostas, e assim eles poderão fazer com que a documentação fique mais fácil de usar.

"Mostre-me."

Uma das melhores maneiras de relatar bugs é mostrá-los aos programadores. Coloque-os em frente ao seu computador, inicie o software e demonstre o erro. Deixe-os observar como você inicia a máquina, como você executa o software e interage com ele e também o que o software faz em resposta às suas entradas.

Eles sabem que o software gosta deles. Sabem quais as partes dele em que confiam, e sabem quais as que mais provavelmente contem falhas. Sabem intuitivamente o que esperar. Quando o software faz alguma coisa obviamente errada, eles já podem ter notado algo sutilmente errado que aconteceu antes disso, e que pode lhes fornecer uma pista. Podem observar tudo que o computador faz durante a execução do teste, e escolher as informações relevantes por si mesmos.

Isso pode não ser o suficiente. Eles podem decidir que precisam de mais informações, e pedir a você para mostrar tudo de novo. Podem pedir a você para ensiná-los a realizar os passos do teste, e assim podem reproduzir o bug para si mesmos quantas vezes desejarem. Podem tentar variar os passos por algumas vezes, para verificar se o problema ocorre apenas em um caso ou em uma família de casos relacionados. Se você for azarado, eles podem precisar usar ferramentas de desenvolvimento por algumas horas e realmente começar a investigar. Mais a coisa mais importante é tê-los olhando para o computador quando o erro acontecer. Uma vez que eles possam ver o problema acontecendo, usualmente podem sair dali e começar a consertá-lo.

"Mostre-me como mostrar a mim mesmo"

Esta é a era da Internet. Esta é a era das comunicações globais. Esta é a era em que eu posso enviar meu software para alguém na Rússia com o toque de um botão, e essa pessoa pode me enviar comentários sobre ele com a mesma facilidade. Mas se essa pessoa verifica um problema com o meu programa, ela não pode me ter em frente ao computador quando ele ocorre. "Mostre-me" é bom quando você pode, mas você muitas vezes não pode.

Se você tem que reportar um bug para um programador que não pode estar com você pessoalmente, o objetivo do exercício é capacitá-lo a reproduzir o problema. Você quer que o programador execute a sua própria cópia do programa, faca as mesmas coisas que você fez com ele e faça-o falhar da mesma maneira. Quando eles podem ver o problema acontecendo em frente aos seus olhos, então eles podem lidar com ele.

Então diga exatamente a eles o que você fez. Se o programa tem uma interface gráfica, diga quais botões você pressionou e em que ordem o fez. Se for um programa que você executa digitando um comando, mostre a eles precisamente que comando você digitou. Sempre que possível você deve fornecer uma transcrição fiel da sessão, mostrando quais comandos você digitou e o que o computador exibiu em resposta.

Dê ao programador toda a informação que você puder imaginar. Se o programa lê um arquivo, você provavelmente precisa enviar uma cópia dele. Se o programa troca dados com outro computador através de uma rede, você provavelmente não poderá enviar uma cópia do outro computador, mas pode ao menos dizer que tipo de computador ele é, e (se você puder obter a informação) que software ele está executando.

"Funciona comigo. Então qual é o erro?"

Se você fornecer a um programador uma longa lista de entradas e ações, e ele executá-las em sua própria máquina e nada der errado, então você não forneceu a ele informações suficientes. Possivelmente a falha não vai aparecer em todos os computadores; seu sistema e o dele podem ser diferentes em alguns pontos. Possivelmente você entendeu mal o que o programa deveria fazer, e vocês estão olhando exatamente para o mesmo resultado na tela e você acha que ela está errada e ele sabe que está certa.

Então, descreva também o que aconteceu. Diga a ele exatamente o que você viu. Diga a ele que você acha que o que viu era errado; melhor ainda, diga a ele exatamente o que você esperava ver. Se você disser apenas “e então deu errado”, deixou de fora informações importantes.

Se você viu mensagens de erro, diga ao programador, cuidadosa e precisamente, o que elas eram. Elas são importantes! Neste estágio, o programador não está tentando consertar o problema; ele está apenas tentando encontrá-lo. Ele precisa saber o que aconteceu de errado, e estas mensagens são o melhor que o computador pode fazer para dizê-lo a você. Anote as mensagens se não houver outra maneira de se lembrar delas; não vale a pena relatar que o programa apresentou erros se você não puder relatar também o conteúdo das mensagens de erro.

Se a mensagem de erro contém números, forneça-os ao programador. Só porque você não consegue ver nenhum significado neles isso não significa que não exista algum. Números contêm todos os tipos de informação que pode ser lida por programadores, e é provável que eles contenham pistas vitais. Números em mensagens de erro estão lá porque o computador está muito confuso para relatar o erro em palavras, mas está dando o melhor de si para fornecer a você a informação de algum jeito.

Neste estágio, o programador está na realidade fazendo um trabalho de detetive. Ele não sabe o que aconteceu, e não pode estar perto o suficiente para ver por si próprio o erro acontecer. Ele está então procurando por pistas que podem dizer o que houve. Mensagens de erro, seqüências incompreensíveis de números e mesmo lentidão inesperada são tão importantes quanto impressões digitais em uma cena de crime. Guarde-as!

Se você está usando Unix, o programa pode ter produzido um dump. Dumps são uma fonte particularmente boa de pistas, então não os jogue fora. Por outro lado, muitos programadores não gostam de receber arquivos imensos de dump por email sem ser avisados disso, então peça permissão antes de enviar esses arquivos para qualquer pessoa. Esteja atento para o fato que o dump contém um registro de todos os dados de estado do programa: quaisquer “segredos” envolvidos (talvez o programa estivesse tratando uma mensagem pessoal, ou trabalhando com dados confidenciais) podem estar contidos no arquivo de dump.

"Então eu tentei…"

Há várias coisas que você pode fazer quando um erro ou bug aparece. Muitas delas tornam o problema pior. Uma das minhas amigas da faculdade apagou todos os seus arquivos do Word por engano, e, antes de chamar por ajuda especializada, tentou reinstalar o Word; depois disso, tentou rodar o Defrag. Nada disso ajudou-a a recuperar seus arquivos, e fazendo isso ela bagunçou de tal maneira o seu HD que nenhum programa de recuperação seria capaz de recuperar nada. Se ela tivesse simplesmente deixado como estava, ela poderia ter tido uma chance de resgatar seus arquivos.

Usuários como ela são como uma fuinha acuada num canto: com as costas na parede e vendo a morte certa pela frente, ela ataca freneticamente, porque fazer alguma coisa tem que ser melhor do que não fazer nada. Esta atitude não é bem adaptada ao tipo de problemas que computadores produzem.

Ao invés de ser uma fuinha, seja um antílope. Quando um antílope se confronta com algo inesperado ou assustador, ele congela. Ele fica absolutamente parado e tenta não atrair nenhuma atenção, enquanto pensa e tenta descobrir a melhor coisa a fazer. (Se houvesse suporte técnico para antílopes, eles o chamariam nestes momentos.) Então, uma vez que eles tenham decidido qual é a coisa mais segura a fazer, eles a fazem.

Quando alguma coisa dá errado, pare imediatamente de fazer qualquer coisa. Não clique qualquer botão. Olhe para a tela e tente perceber qualquer coisa fora do comum, e memorize-a ou anote-a. Então, cautelosamente, pressione "OK" ou "Cancel", o que parecer mais seguro. Tente desenvolver um ato reflexo - se um computador fizer algo inesperado, congele.

Se você conseguir se safar do problema, seja fechando o programa afetado ou reiniciando o computador, uma boa coisa a fazer é tentar reproduzir novamente o erro. Programadores gostam de problemas que eles possam reproduzir. Programadores felizes consertam bugs mais rapidamente e com mais eficácia.

"Acho que a modulação do tachyon deve estar com a polarização errada."

Maus relatórios de bug não são produzidos somente por não-programadores. Alguns dos piores relatórios que eu já vi foram feitos por programadores, e algumas vezes por programadores.

Uma vez eu trabalhei com um programador que encontrava bugs em seu próprio código e tentava consertá-los. Muitas vezes ele achava um bug que não conseguia resolver, e me chamava para ajudar. "O que deu errado?", eu perguntava. Ele me respondia dizendo qual a sua opinião sobre o que precisava de ser consertado.

Isto funcionava bem quando a opinião dele estava certa. Isto significava que ele já tinha feito metade do trabalho, e que conseguiríamos finalizar o restante juntos. Era eficiente e útil.

Mas era muito diferente quando ele estava errado. Trabalhávamos por algum tempo tentando descobrir porque uma parte específica do programa estava produzindo dados incorretos, e eventualmente descobríamos que não estava, que estivéramos investigando código perfeitamente funcional por meia hora, e que o problema real estava em outro lugar.

Estou certo de que ele não agiria assim com um médico. "Doutor, preciso de uma receita para Hidroioiodina." As pessoas sabem que não podem dizer isso a um médico: você descreve os sintomas, os desconfortos reais e as dores, as erupções, as febres, e deixa o doutor fazer o diagnóstico de qual é o problema e o que fazer para resolvê-lo. Se não for assim, o doutor acha que você é um hipocondríaco ou drogado e te manda embora, o que é certíssimo.

É a mesma coisa com programadores. Fornecer seu próprio diagnóstico pode ser útil às vezes, mas sempre diga os sintomas. O diagnóstico é um extra opcional e não uma alternativa a fornecer os sintomas. Da mesma maneira, enviar o código-fonte com o conserto do problema é um acréscimo útil a um relatório de bugs, mas não um substituto para ele.

Se um programador pede informação extra a você, colabore! Uma vez alguém me relatou um problema, e eu pedi a essa pessoa para executar um comando que eu sabia que não funcionava. Pedi isso a ela porque queria saber qual das duas mensagens de erro possíveis o comando geraria. Saber isso forneceria uma pista vital. Mas a pessoa não executou o comando - ela só me enviou um email dizendo "Não, isso não vai funcionar.". Levou algum tempo até que eu a convencesse a realmente executar o comando.

Usar sua inteligência para ajudar os programadores é ótimo. Mesmo que suas deduções estejam erradas, eles seriam gratos pela sua tentativa de tornar a vida deles mais fácil. Mas relate os sintomas também, ou você com certeza vai tornar a vida deles muito mais difícil.

"Engraçado, consegui fazer isso há cinco minutos sem problemas."

Diga “problema intermitente” para qualquer programador e veja a careta que ele faz. Os problemas fáceis são aqueles onde repetir uma seqüência de passos simples vai fazer com que o erro ocorra. O programador pode então repetir estas ações em condições de teste bastante monitoradas e ver o que acontece com grande detalhe. Muitos problemas simplesmente não acontecem dessa forma: vai haver programas que falham uma vez por semana, uma vez a cada lua cheia, ou nunca falham quando você tenta reproduzi-los diante do programador, mas sempre falham quando você tem um prazo apertado para cumprir.

A maior parte dos problemas intermitentes não é verdadeiramente intermitente. Muitos deles têm uma lógica escondida em algum lugar. Alguns ocorrem somente quando a máquina está com pouca memória disponível, alguns acontecem apenas quando outro programa tenta modificar um arquivo crítico no momento errado, e alguns outros ocorrerão somente na primeira metade de cada hora! (Eu realmente vi alguns desses.)

Se você consegue reproduzir o bug, mas o programador não, uma causa provável é que o seu computador e o dele são diferentes de alguma maneira e esta diferença é a causa do problema. Eu tive um programa cuja janela se enrolava em uma pequena bola no canto superior esquerdo da tela, ficava lá me aborrecendo . Mas ele só fazia isso em telas com resolução de 800x600 pixels; executava normalmente em meu monitor de 1024x768.

O programador vai querer saber tudo o que você puder descobrir sobre o problema. Tentar reproduzi-lo em outra máquina, talvez. Tente reproduzi-lo duas ou três vezes e ver quantas vezes ele falha. Se ele acontece quando você está fazendo uma tarefa importante, mas não quando está tentando demonstrá-lo, a causa da falha pode ser o grande tempo de execução ou o tratamento de grandes arquivos. Tente lembrar com quantos detalhes puder sobre o que você estava fazendo quando o erro ocorreu e, se identificar padrões, mencione-os. Tudo o que você puder fornecer pode ajudar. Mesmo que seja somente uma informação probabilística (como “o programa tende a falhar quando o Emacs está executando”) que não forneça pistas diretas sobre a causa do problema, ela pode ajudar o programador a reproduzir o erro.

Mais importante ainda, o programador vai querer estar certo de que ele está lidando com um verdadeiro problema intermitente ou com um problema específico da sua máquina. Ele vai querer saber montes de detalhes sobre seu computador, para assim poder descobrir como o computador dele difere do seu. Vários destes detalhes vão depender especificamente do programa, mas algo que você deve estar definitivamente pronto para fornecer são números de versão. O número de versão do programa em si, o do sistema operacional e provavelmente os de qualquer outro programa que esteja envolvido no problema.

"Então eu carreguei o disco no meu Windows..."

Em relatórios de bug, escrever claramente é essencial. Se o programador não consegue entender o que você quis dizer, era preferível que você não tivesse dito nada.

Eu recebo relatórios de bug de todas as partes do mundo. Muitos deles vêm de pessoas que não têm o inglês como sua língua-mãe, e muitos deles pedem desculpas pelo seu inglês ruim. Em geral, os relatórios de bug que contêm pedidos de desculpas pelo mau inglês são realmente claros e úteis. Todos os relatórios mais confusos vêm de pessoas cuja língua-mãe é o inglês e que presumem que eu vou entendê-los mesmo que não façam qualquer esforço por clareza e precisão.

• Seja específico. Se você puder fazer a mesma coisa de duas maneiras diferentes, diga qual delas usou. "Eu selecionei a opção Carregar" pode significar "Eu cliquei o botão Carregar" ou "Eu pressionei Alt-L". Diga qual delas você usou. Algumas vezes isso é importante.
• Seja prolixo. Dê mais informação ao invés de menos. Se você der informações demais, o programador pode ignorar algumas delas. Se você der informações de menos, eles tem que voltar a você e perguntar mais. Uma vez tive que gastar semanas para conseguir uma quantidade de informações que fosse útil, porque elas apareciam em pequenas frases de cada vez.
• Seja cuidadoso com os pronomes. Não use palavras como "isso", ou referências como "a janela" quando o que elas puderem significar não for totalmente claro. Considere a frase: "Eu iniciei o programa FooApp. Ele mostrou uma janela de advertência. Tentei fechar e ele travou." Não está claro o que o usuário tentou fechar. Foi a janela de advertência ou a aplicação FooApp? Isso faz diferença. Ao invés disso, ele poderia ter dito "Eu iniciei o programa FooApp, que mostrou uma janela de advertência. Tentei fechar esta janela, e o programa travou.". Esta última frase é mais longa e mais repetitiva, mas também é mais clara e menos propensa a ambiguidades.
• Leia o que você escreveu. Leia o relatório para você mesmo, e verifique se o que você pensou está claro. Se você fez uma lista de passos que deveriam produzir a falha, tente segui-los você mesmo, para verificar se esqueceu algum deles.

Sumário

• O objetivo principal de um relatório de bugs é permitir que os programadores possam ver o erro com seus próprios olhos. Se você não pode estar com eles pessoalmente para reproduzir a falha, dê-lhes instruções detalhadas para que possam reproduzir a falha por si próprios..
• No caso de o objetivo principal não ter sido alcançado e os programadores não puderem ver a falha por si mesmos, o segundo objetivo de um relatório de bug é descrever o que aconteceu de errado. Descreva tudo em detalhes. Diga o que você viu, e também o que esperaria ver acontecer. Escreva as mensagens de erro, especialmente se elas contém números.
• Quando o seu computador fizer alguma coisa inesperada, pare.Não faça nada até que esteja calmo, e não faça nada que você ache que possa ser perigoso.
• Tente por todos os meios diagnosticar a falha por você mesmo se acha que pode fazê-lo; mas mesmo que faça isso, você ainda deve relatar os sintomas.
• Esteja pronto para fornecer informações extras no caso de os programadores precisarem delas. Se eles não precisassem, não as pediriam. Eles não estão sendo deliberadamente inábeis. Tenha os números de versão do programa à mão, porque provavelmente eles serão necessários.
• Escreva com clareza. Diga o que tem para dizer, e esteja certo de que o texto não possa ser mal interpretado.
• Acima de tudo, seja preciso. Programadores gostam de precisão.

---

Aviso de negação de responsabilidade : Nunca vi uma fuinha ou um antílope ao vivo. Minha zoologia pode ser inexata.

Copyright © 1999 Simon Tatham.
Este documento é OpenContent. Você pode copíá-lo e usar partes do texto nos termos da Licença OpenContent.
Por favor envie comentários e críticas para anakin@pobox.com.
Se você chegou até est página através do site de um software específico, não envie relatórios de bug deste software para o endereço acima. Retorne à página em que estava e encontre nela onde reportar bugs para o software em questão.

retirado de: http://www.chiark.greenend.org.uk/~sgtatham/bugs-br.html