Microsoft Office

O artigo de hoje é curto e não é sobre programação. É sobre compra de software da MS. Tentei comprar o Office Home & Student hoje via internet. Incrível, mas provavelmente é mais difícil comprar do que usar uma versão pirata.

Depois de duas horas de trabalho infrutífero e frustrante, finalmente consegui ao menos baixar uma versão de avaliação do 2010. Desagradável que no final, por eu estar no Brasil, ele não deu muita atenção ao meu pedido inicial de baixar a versão em inglês e, em algum dos milhares de reloads de página que precisei dar, deve ter mudado para pt_BR sem eu notar. Resultado: Estou novamente tentando baixar a versão em inglês. Agradeci a todas as divindades de todas as religiões que eu estava baixando o trial version e não tinha feito nenhum pagamento...

Resumindo, além de ser caro, o Office é difícil de ser comprado. A não ser que esta versão seja realmente maravilhosa e me surpreenda muito durante o trial, vou acabar mesmo é usando Google Docs para editar documentos. (E viva o SaaS...)

O procedimento de correção de bug

Pessoal, parece incrível, mas a maioria das pessoas não tem a menor noção dos passos básicos para corrigir um bug. Então, decidi escrever um pequeno texto falando sobre isto.

Vamos começar definindo o que é um bug. Bug é um resultado obtido que é diferente do desejado. Trata-se de um defeito.

Assim sendo, a correção do bug deve começar com uma indicação clara do defeito, ou seja, com um bom bug report. Buenas, não adianta inventar no bug report, nem usar ferramentas com milhares de campos, nem com letras em ouro. O que resolve é ter claramente no report as seguintes informações:

• Passos que fazem com que o resultado indesejado (o bug) aconteça de forma determinística. De forma determinística significa: aconteça SEMPRE que eu seguir aqueles passos e sem precisar de nada mais...
  Por que isto é importante? Porque sem ter um modo consistente de fazer o bug manifestar-se, a pessoa que vai tentar corrigir teria de agir por adivinhação e isto não é nem muito científico nem muito profissional.
• Resultado esperado.
  Por que é importante? Para o corretor saber quando ele chegou onde devia.
• Resultado obtido.
  Por que é importante? Para o corretor saber se ele realmente está vendo O MESMO bug que quem reportou (o reporter).
• Versão do software em que o bug foi visto.
  Não queremos perder tempo tentando corrigir algo que já foi corrigido em um patch, service pack ou versão mais nova...

Tendo isto, podemos começar o processo de investigação e correção:

1. Reproduza o bug.
1. Instale EXATAMENTE a mesma versão do software indicada no report. Use o instalador que foi para campo e não uma recompilação de fontes.
2. Siga os passos de como reproduzir o bug.
3. Certifique-se de que obteve o "resultado obtido" citado no report.
2. Reproduza o bug compilando os fontes.
   Faça isto seguindo os mesmos passo que no item anterior, mas recompile o software a partir dos fontes em que vai trabalhar. Você vai se surpreender com a quantidade de vezes que, mesmo após ter passado no passo anterior, com os fontes de trabalho, o bug não aparece.
3. Investigue a causa raiz do bug.
   Aqui entram em cena as ferramentas de depuração: debugger, instrumentação de código, código dos unittests, inteligência e experiência do corretor, etc. É impossível descrever em detalhes como se faz isto, e só sobre este item eu poderia escrever vários artigos, então aqui vamos apenas dizer que tem de investigar até achar a causa do bug.
4. Arrume seus unittests para pegarem o erro.
   Seus unittest não pegaram o erro anteriormente, pois ele foi visto por alguém. Então há uma falha nos unittests e ela deve ser corrigida. Ao fim deste passo, seu unittest deve estar apontando um erro.
5. Altere o código para corrigir o bug.
   Certifique-se também de que agora os unittests estão passando. A propósito, use os unittest do módulo sendo alterado como auxiliar na alteração do código, ou seja, não compile o software inteiro antes que o unittest do módulo alterado esteja passando.
6. Rode TODOS os unittests do software.
   Isto vai deixá-lo mais seguro de que nada foi quebrado no conserto.
7. Faça um rebuild incluindo as correções.
8. Re-execute os passos descritos no bug report e certifique-se de que o resultado esperado agora é obtido.
9. Levante (ao menos mentalmente) as possíveis áreas adjacentes do software que podem ter tido efeitos colaterais com sua mexida e TESTE-AS.
10. Se o bug não foi encontrado como resultado da execução de seus testes internos, revise seu plano de teste para incluir um caso de teste que pegue o bug.

Pronto. Agora você tem um bug corrigido apropriadamente e com maiores chances de sucesso.

Os princípios que norteiam este processo são:

• Trabalho metódico: sem adivinhações, basear-se em fatos.
• Melhoria contínua: melhorar as redes de proteção (unittests e plano de testes) quando um bug passa por elas e a cada novo bug elas ficam melhores.
• One var is gooood, two vars is baaaaad: Uma variável é bom, duas variáveis é ruim.... Mude sempre apenas uma coisa de cada vez. -- a propósito, a frase é uma brincadeira com o slogan das ovelhas do Animal Farm.

Abraços e até o próximo artigo.

Inauguração do BLOG

Buenas, então vamos a uma breve introdução sobre este blog.

Originalmente, eu criei uma página com artigos em http://www.lgmoreira.com, mas está me parecendo que escrever e gerenciar a página com o google sites é meio enfadonho e que é mais simples com um blog. Por isso, criei o blog aqui e vou passar os artigos da página para cá.

No começo, vou tentar manter o material nos dois locais. Mas com o tempo, vou optar por um deles e deixar no outro apenas um link para o local escolhido.

Abraços e até mais.

PS: Não esqueçam que este trabalho é voluntário e, no caso de alguém querer contribuir com alguns reais pelo trabalho, pode fazer através do SourceForge.